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Abstract 

Previous  efforts  by  the  US  Army  Engineer  Research  and  Development 
Center,  Construction  Engineering  Research  Laboratory  (ERDC-CERL)  to 
develop  a  life-cycle  building  model  have  resulted  in  the  definition  of  a 
“core”  building  information  model  that  contains  general  information  de¬ 
scribing  facility  assets  such  as  spaces  and  equipment.  To  describe  how  fa¬ 
cility  assets  (i.e.,  components)  function  together,  information  about 
assemblies  of  assets  and  their  connections  must  also  be  defined.  The  defi¬ 
nitions  of  assets,  assemblies,  and  connections  for  the  various  building- 
information  domains  are  discipline-specific. 

The  work  documented  here  addresses  the  process  flow  and  data  exchange 
requirements  for  the  design  of  electrical  distribution  systems  in  typical 
Army  facilities.  This  ontology  advances  the  state  of  the  art  by  defining  an 
Industry  Foundation  Class  (IFC)  Model  View  for  electrical  system  design 
supporting  end  users  in  developing  compliant  BIM  models  suggesting  po¬ 
tential  areas  of  automation  in  electrical  system  design. 


DISCLAIMER:  The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication,  or  promotional  purposes. 
Citation  of  trade  names  does  not  constitute  an  official  endorsement  or  approval  of  the  use  of  such  commercial  products. 
All  product  names  and  trademarks  cited  are  the  property  of  their  respective  owners.  The  findings  of  this  report  are  not  to 
be  construed  as  an  official  Department  of  the  Army  position  unless  so  designated  by  other  authorized  documents. 
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Unit  Conversion  Factors 


Multiply 

By 

To  Obtain 

acres 

4,046.873 

square  meters 

acre-feet 

1,233.5 

cubic  meters 

angstroms 

0.1 

nanometers 

atmosphere  (standard) 

101.325 

kilopascals 

bars 

100 

kilopascals 

British  thermal  units  (International  Table) 

1,055.056 

joules 

centi  poises 

0.001 

pascal  seconds 

centistokes 

1.0  E-06 

square  meters  per  second 

cubic  feet 

0.02831685 

cubic  meters 

cubic  inches 

1.6387064  E-05 

cubic  meters 

cubic  yards 

0.7645549 

cubic  meters 

degrees  (angle) 

0.01745329 

radians 

degrees  Fahrenheit 

(F-32)/1.8 

degrees  Celsius 

fathoms 

1.8288 

meters 

feet 

0.3048 

meters 

foot-pounds  force 

1.355818 

joules 

gallons  (US  liquid) 

3.785412  E-03 

cubic  meters 

hectares 

1.0  E+04 

square  meters 

horsepower  (550  foot-pounds  force  per  second) 

745.6999 

watts 

inches 

0.0254 

meters 

inch-pounds  (force) 

0.1129848 

newton  meters 

kilotons  (nuclear  equivalent  of  TNT) 

4.184 

terajoules 

knots 

0.5144444 

meters  per  second 

microinches 

0.0254 

micrometers 

microns 

1.0  E-06 

meters 

miles  (nautical) 

1,852 

meters 

miles  (US  statute) 

1,609.347 

meters 

miles  per  hour 

0.44704 

meters  per  second 

mils 

0.0254 

millimeters 

ounces  (mass) 

0.02834952 

kilograms 

ounces  (US  fluid) 

2.957353  E-05 

cubic  meters 

pints  (US  liquid) 

4.73176  E-04 

cubic  meters 
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Multiply 

By 

To  Obtain 

pints  (US  liquid) 

0.473176 

liters 

pounds  (force) 

4.448222 

newtons 

pounds  (force)  per  foot 

14.59390 

newtons  per  meter 

pounds  (force)  per  inch 

175.1268 

newtons  per  meter 

pounds  (force)  per  square  foot 

47.88026 

pascals 

pounds  (force)  per  square  inch 

6.894757 

kilopascals 

pounds  (mass) 

0.45359237 

kilograms 

pounds  (mass)  per  cubic  foot 

16.01846 

kilograms  per  cubic  meter 

pounds  (mass)  per  cubic  inch 

2.757990  E+04 

kilograms  per  cubic  meter 

pounds  (mass)  per  square  foot 

4.882428 

kilograms  per  square  meter 

pounds  (mass)  per  square  yard 

0.542492 

kilograms  per  square  meter 

quarts  (US  liquid) 

9.463529  E-04 

cubic  meters 

slugs 

14.59390 

kilograms 

square  feet 

0.09290304 

square  meters 

square  inches 

6.4516  E-04 

square  meters 

square  miles 

2.589998  E+06 

square  meters 

square  yards 

0.8361274 

square  meters 

tons  (force) 

8,896.443 

newtons 

tons  (force)  per  square  foot 

95.76052 

kilopascals 

tons  (long)  per  cubic  yard 

1,328.939 

kilograms  per  cubic  meter 

tons  (nuclear  equivalent  of  TNT) 

4.184  E+09 

joules 

tons  (2,000  pounds,  mass) 

907.1847 

kilograms 

tons  (2,000  pounds,  mass)  per  square  foot 

9,764.856 

kilograms  per  square  meter 

yards 

0.9144 

meters 

ERDC/CERL  CR-13-2 


1 


1  Introduction 

1.1  Background 

Previous  efforts  by  the  US  Army  Engineer  Research  and  Development 
Center,  Construction  Engineering  Research  Laboratory  (ERDC-CERL)  to 
develop  a  life-cycle  building  model  have  resulted  in  the  definition  of  a 
“core”  building  information  model  that  contains  general  information  de¬ 
scribing  facility  assets  such  as  spaces  and  equipment  (East,  Love,  and 
Nisbet  2010).  To  describe  how  facility  assets  (i.e.,  components)  function 
together,  information  about  assemblies  of  assets  and  their  connections 
must  also  be  defined.  The  definitions  of  assets,  assemblies,  and  connec¬ 
tions  for  the  various  building-information  domains  are  discipline-specific. 
Taken  together,  studies  of  all  essential  building-information  domains  will 
create  a  unified  framework  for  developing  automatic  design  checks,  ensur¬ 
ing  construction  compliance,  improving  operations  and  maintenance  effi¬ 
ciency,  and  evaluating  alternatives  for  redesign  within  completed  facilities. 

COBie  (East  2012a)  was  the  first  step  in  analyzing  information  exchanges 
in  the  life  cycle  of  a  building.  Since  March  2012,  COBie  has  been  part  of 
the  National  BIM  Standard-United  States  (NBIMS-US).  COBie  defines  the 
format  for  providing  information  about  building  assets  from  the  planning 
phase  through  design,  construction,  and  operations.  Properties  of  these 
assets  may  also  be  captured  in  the  COBie  date  exchange  format.  The 
COBie  Guide,  a  commentary  on  the  COBie  standard  (public  draft  down¬ 
loadable  at  link  from  http://www.nibs.prg/?page=bsa  cabieguide).  does  not  prescribe 
how  to  model  specific  assemblies  of  components  or  how  components  and 
assemblies  are  connected  (East  2007,  East  2012a).  Those  aspects  of  mod¬ 
eling  and  information  exchange  require  a  domain-specific  ontology  for 
every  system  needed  to  construct  a  functional  building. 

The  work  documented  here  addresses  the  process  flow  and  data  exchange 
requirements  for  the  design  of  electrical  distribution  systems  in  typical 
Army  facilities.  This  ontology  advances  the  state  of  the  art  by 

1.  defining  an  Industry  Foundation  Class  (IFC)  Model  View  for  electrical 
system  design 

2.  supporting  end  users  in  developing  compliant  BIM  models 

3.  suggesting  potential  areas  of  automation  in  electrical  system  design. 
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1.2  Objectives 

The  objectives  of  the  present  work  were  to  identify  and  document  the  re¬ 
quirements  for  building  electrical  system  design  for  the  purpose  of  creat¬ 
ing  formal  specifications  that  can  be  directly  applied  to  open-standards 
building  information  models  (BIM)  at  the  coordinated  design  stage  of 
building  construction. 

1.3  Approach 

To  document  the  process  and  exchange  requirements,  the  team  followed 
the  Information  Delivery  Manual  (IDM)  and  Model  View  Definition 
(MVD)  procedures  defined  by  the  International  Organization  for  Stand¬ 
ardization  (ISO)  and  buildingSmart  International  (e.g.,  Wix  2007, 
Hietanen  2008).  Validation  of  the  process  diagrams  and  exchange  re¬ 
quirements  followed  the  process  outlined  below: 

1.  Create  drafts  of  process  diagrams  and  task  descriptions  for  each  of 
three  phases  of  the  design  process— Criteria  (i.e.,  Programming  and 
Concept  Design),  Schematic  Design  (i.e.,  Design  Development),  and 
Coordinated  Design  (i.e.,  Construction  Documents).  The  draft  process 
diagrams  included  suggested  steps  for  the  typical  Army  design  process, 
and  the  task  descriptions  included  suggested  information  requirements 
needed  to  accomplish  the  task  step. 

2.  Assemble  a  group  of  subject  matter  experts  (SMEs)  to  review  and 
comment  on  the  draft  process  diagrams  and  task  descriptions.  This 
group  included  two  architects,  two  engineers,  and  two  specifiers  with 
experience  in  the  design  of  building  electrical  systems. 

3.  Meet  with  the  SME  reviewers  to  explain  the  process  and  review  crite¬ 
ria. 

4.  Send  the  process  diagrams  and  task  descriptions  to  the  SMEs  for  their 
review. 

5.  Analyze  the  SME  comments  and  contact  the  SMEs  for  clarification  and 
additional  comments,  as  needed. 

6.  Revise  the  process  diagrams  and  task  descriptions  based  on  the  SME 
comments. 

The  research  team  also  consulted  a  publication  on  ELie  (East  2012c)  and 
unpublished  research  notes  on  the  exploratory  modeling  of  electrical  sys¬ 
tem  components  and  connections,  called  SPARKie  (East  2012b). 
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The  specific  selection  and  sequencing  of  tasks  was  intended  as  a  starting 
point  that  would  be  refined  using  the  SME  reviewers’  feedback.  The  task 
forms  included  the  information  summarized  in  Table  l 


Table  1.  Task  form  description. 


Item 

Description 

Task  ID 

Sequential  ID  number  for  the  task. 

Task  Name 

A  short  descriptive  name  for  the  task 

Information  Provider 
(Roles  Involved) 

The  role  or  roles  that  provide  the  input  information 
necessary  to  do  the  task. 

Information  Provider 
(Phase) 

The  stage  in  the  process  when  the  required  information 
is  created. 

Actor  (Roles  Involved) 

The  role  or  roles  that  complete  the  task. 

Actor  (Phase) 

The  stage  in  the  process  at  which  the  task  requires  the 
information. 

Information  Required 

The  input  information  necessary  to  complete  the  task. 

Current  Methods 

A  short  description  of  the  task  and  its  inputs  and 
outputs. 

The  experts  were  asked  to  review  the  tasks  with  the  following  questions  in 
mind: 

•  Do  the  task  forms  accurately  and  completely  detail  all  information 
needed  to  perform  the  task? 

o  If  not,  what  is  missing? 
o  Who  provides  the  additional  inputs? 

•  Are  current  methods  of  performing  the  task  accurately  described? 

For  the  process  diagrams,  the  reviewers  were  asked: 

•  Although  every  project  has  unique  circumstances,  are  the  tasks  shown 
in  the  typically  correct  order? 

•  Have  we  missed  any  tasks? 

•  Are  there  any  unnecessary  tasks? 

•  Are  all  tasks  assigned  to  the  correct  phase(s)? 

•  Are  all  tasks  assigned  to  the  correct  actor? 

•  Are  all  actors  that  provide  the  Information  Required  indicated? 

•  Are  any  extraneous  actors  indicated? 


Table  2  lists  the  expert  reviewers  and  pertinent  background  information. 
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Table  2.  Subject  matter  experts. 


Name 

Organization 

Area  of  Expertise 

Randy  Deutsch  AIA,  LEED 
AP 

Deutsch  Insights,  Inc. 

Architect 

Senior  Architectural  Designer  &  Associate  Principal  with 
proven  track  record  for  design  leadership.  Demonstrated 
success  designing  and  managing  complex  projects 
including  high-rises,  retail,  mixed-use  developments, 
housing  &  master  plans.  Professional  thought  leader, 
presenter,  instructor,  mentor  &  author.  Instrumental  in 
firm-wide  BIM  and  IPD  adoption  &  implementation.  AIA 
Young  Architect  Award  recipient.  University  building 
technology,  design  studio  &  professional  practice 
instructor.  Author  of  BIM  and  Integrated  Design  (Wiley 
2011). 

Susan  F.  King,  FAIA,  LEED 
AP  BD+C 

Harley  Ellis  Devereaux 

Architect 

As  a  principal  with  Harley  Ellis  Devereaux,  Susan  King  is 
the  firm’s  National  Sustainable  Design  Leader, 
developing  and  implementing  nationwide  design  policies 
in  regards  to  sustainability.  A  practicing  architect  with  25 
years  of  experience,  she  has  lead  numerous  multi¬ 
disciplinary  sustainable  developments  teams  on  projects 
ranging  in  scale  from  urban  infill  for  newly  constructed 
housing  to  the  repurposing  of  existing  structures  to  the 
master  planning  study  of  the  35  acre  Chicago  2016 
Olympic  Village  site.  A  true  collaborator,  Susan  joins 
design  teams  with  ease  and  a  practical  approach  to  the 
integrated  design  process.  An  advocate  for  green  market 
transformation  of  the  building  industry,  Ms.  King  is 
routinely  invited  to  speak  on  sustainable  design  topics. 

Jim  Forester 

Newforma,  Inc. 

Engineer 

California  P.E.  license  M24307.  Co-Founder  and  Senior 
Technical  Advisor  at  Newforma,  Inc.  Original  member  of 
the  buildingSmart  International  Model  Support  Group.  1 
was  involved  with  the  many  of  the  original  definitions  of 
the  building  services  concepts  and  how  they  are 
connected,  including  the  underlying  graph 
representations  supporting  both  symbolic  and  physical 
connectivity  that  would  support  mass  and  energy  flow 
simulations. 
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Name 

Organization 

Area  of  Expertise 

Kenneth  Solvik 

Data  Design  System 

Engineer 

Master  of  Management.  Electrical  Engineer,  specialized 
field  installation,  automation,  building  control  and 
programming. 

CTO  and  R&D  coordinator.  Manager  and  participant  in 
multiple  R&D  projects.  IFC  (EL-1  &  EL-2),  MEP  Quantity 
Take  Off  (IDM),  MEP  Fast  and  Easy  planning,  Innovative 
MEP  design  and  simulations  process,  BIM  enhancer  & 

BIM  energy  efficiency  optimizer. 

Mark  Kalin  FAIA  FCSI 

LEED 

Kalin  Associates 

Specifier 

Registered  architect,  CSI-certified  construction  specifier, 
LEED-accredited  professional,  and  one  of  only  27 
individuals  ever  advanced  to  fellowship  in  both  the 
American  Institute  of  Architects  and  the  Construction 
Specifications  Institute.  Author  of  numerous  publications 
on  specifications,  product  selection,  and  green  specs, 
who  has  presented  more  than  100  sessions  at  regional 
and  national  conventions.  He  has  taught  architectural 
specifications  at  Harvard  University  Graduate  School  of 
Design  and  is  currently  chair  of  the  Sustainable  Facilities 
Practice  Group  of  the  Construction  Specifications 

Institute. 

Chris  Nelson 

Nelson  Electric 

Specifier 

Chris  specifies  and  designs  electrical  systems  on 
commercial  and  industrial  building  projects  at  Nelson 
Electric  in  Ames,  Iowa.  Previously,  he  served  as 

Enterprise  Systems  Manager  at  The  Weitz  Company  for  9 
years,  where  he  had  significant  experience  leading 
Building  Information  Modeling  initiatives.  He  was  also  a 
Project  Engineer  at  The  Meyne  Company  for  2  years.  He 
has  an  MBA  from  the  University  of  Iowa,  an  MS  in  Civil  & 
Construction  Engineering  from  Iowa  State  University,  and 
a  BS  in  Chemical  Engineering  from  Iowa  State  University. 

1.4  Scope 

The  scope  of  the  work  documented  here  was  to  diagram  the  electrical  sys¬ 
tem  design  process,  and  to  identify  and  document  the  relevant  data  ex¬ 
changes.  A  separate  report  (ERDC/CERL  CR-13-3)  applies  this  ontology  to 
the  updating  of  three  previously  developed  experimental  BIM  models  us¬ 
ing  commercial  off-the-shelf  (COTS)  software.  Those  models  represent 
three  types  of  typical  low-rise  Army  facilities:  a  duplex  apartment,  an  of¬ 
fice  building,  and  a  medical  clinic.  The  experimental  application  work 
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identifies  some  current  product  limitations  in  achieving  successful  infor¬ 
mation  exchange. 

1.5  Mode  of  technology  transfer 

Documentation  of  this  ontology  will  be  used  as  the  basis  for  a  ballot  sub¬ 
mission  to  the  National  BIM  Standard-United  States.  Model  files  created 
for  the  related  validation  application  (ERDC/CERL  CR-13-3)  will  be  made 
publicly  available  for  testing  and  evaluation  of  the  proposed  open  BIM 
standard  that  results  from  this  work. 
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2  Electrical  System  Design  Process  Models 

2.1  Overview 

Building  design  is  a  highly  iterative  process  during  which  information  is 
gathered,  design  options  are  evaluated  and  selections  are  made.  The  goal 
is  to  achieve  a  final  design  in  which  aesthetics,  cost  and  systems  perfor¬ 
mance  are  all  optimized.  During  design,  each  choice  has  multiple  effects. 
Optimized  design  can  only  be  achieved  through  multiple  iterations  of  in¬ 
terdependent  analyses. 

Today’s  designers  and  owners  seek  to  optimize  multiple  aspects  of  a  build¬ 
ing,  including  first  cost,  life  cycle  cost  and  environmental  impact.  Early 
adopters  of  building  information  modeling  technology  have  demonstrated 
that  the  use  of  computable  building  models,  coupled  with  the  availability 
of  analysis  software,  facilitates  and  reduces  cycle  times  of  the  iterations 
necessary  to  achieve  such  optimization  (Fallon  and  Palmer  2007).  The 
purpose  of  this  electrical  systems  ontology  is  to  define  a  standardized 
computable  description  of  all  electrical  system  parameters  necessary  for  a 
complete  design.  The  availability  of  such  a  standardized,  computable  de¬ 
scription  supports  the  development  and  use  of  electrical  system  design  au¬ 
tomation  software. 

2.1.1  Electrical  system  design  process 

The  design  of  building  electrical  systems  iterates  through  multiple  steps, 
involving  multiple  parties  and  the  repeated  refinement  of  the  design  as  it 
moves  from  generalized  concepts  and  equipment  types  to  detailed  con¬ 
struction  documents  with  the  required  equipment  specified.  The  process 
diagrams  in  this  document  focus  on  the  design  tasks  and  data  exchanges 
involving  the  Architect  and  Electrical  Engineer.  Data  required  from  other 
project  participants  are  also  documented. 

2.1.2  Electrical  system  design  phases 

The  design  process  documented  in  this  report  is  divided  into  three  general 
phases,  typical  of  the  Design-Bid-Build  process  for  USACE  projects.  Alt¬ 
hough  the  sequence  of  tasks  and  even  the  actors  for  each  task  can  vary, 
depending  on  project  delivery  approach  and  on  the  internal  organization 
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of  the  professional  services  provider  company (ies),  the  tasks  that  must  be 
completed  and  the  information  required  remain  constant. 

2. 1.2.1  Criteria  (Programming  and  Concept  Design) 

The  Criteria  phase  requires  gathering  the  necessary  information  that  will 
define  the  project’s  scope,  budget,  and  overall  goals.  The  Owner’s  Project 
Requirements  (OPR),  building  codes,  site  location,  and  sustainability  goals 
are  all  indentified  during  this  phase.  Once  the  building  program  has  been 
developed,  the  Facility  Occupancy  Model  can  be  determined.  This  infor¬ 
mation  allows  the  Architect  and  Electrical  Engineer  to  develop  a  Concept 
Design.  Typically,  several  options  are  created  to  compare  designs  or  sys¬ 
tem  alternatives. 

2. 1.2.2  Schematic  design  (Design  Development) 

The  Schematic  Design  phase  requires  using  the  information  developed 
during  the  Criteria  phase  to  develop  the  building  design  further.  For  elec¬ 
trical  systems  design,  most  of  the  information  is  generated  by  the  Electri¬ 
cal  Engineer.  The  Architect  provides  information  regarding  electrical  load 
types  and  locations.  Other  consultants  will  provide  electrical  requirements 
for  other  building  systems.  This  information  allows  the  Electrical  Engineer 
to  determine  the  overall  electricity  demand.  During  this  phase,  specifica¬ 
tions  for  the  anticipated  equipment  are  developed  in  addition  to  the  draw¬ 
ings.  The  specifications  identify  performance  requirements  for  the  various 
electrical  system  components. 

2. 1.2.3  Coordinated  design  (Construction  Documents) 

The  Coordinated  Design  phase  involves  finalizing  the  documents  in  prepa¬ 
ration  for  bidding  and  construction.  Primarily,  this  involves  updating  the 
drawings  and  specifications  completed  in  the  previous  phases  with  more 
detailed,  accurate  information  about  the  building  and  systems.  Again,  this 
requires  that  the  Electrical  Engineer  receive  input  from  the  Architect  and 
any  others  involved  whose  particular  discipline  could  have  an  impact  on 
the  electrical  system  design. 

2.2  Specification  of  processes 

This  section  contains  three  Process  Diagrams  covering  the  electrical  sys¬ 
tem  design  phases  of  (l)  Criteria  (Programming  and  Concept  Design),  (2) 
Schematic  Design  (Design  Development)  and  (3)  Coordinated  Design 
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(Construction  Documents).  These  phases  have  been  assigned  an  arbitrary 
sequential  number  (to,  20  or  30)  to  aid  in  tracking  and  coordinating  tasks. 
Following  each  of  the  three  diagrams  are  tabular  descriptions  of  the  tasks 
shown  in  each  diagram. 

The  diagrams  and  task  descriptions  have  been  revised  to  reflect  the  re¬ 
views  and  comments  made  by  the  SMEs.  Several  of  the  reviewers  suggest¬ 
ed  alternative  process  flows,  based  on  their  experience  with  specific  types 
of  projects  and  project  delivery  approaches  -  Design-Build  versus  Design- 
Bid-Build,  for  example.  The  suggestions  were  evaluated  and,  in  some  cas¬ 
es,  the  original  flow  was  modified.  Even  where  the  workflow  differed,  how¬ 
ever,  the  design  tasks  and  information  requirements  have  remained  the 
same. 

The  solidification  of  the  design  involves  an  iterative  process,  where  the 
owner,  architect,  the  plumbing  engineer  and  other  specialists  must  recon¬ 
cile  their  needs  with  those  of  others.  An  explicit  understanding  of  the  pro¬ 
cess  and  its  information  requirements  can  help  streamline  the  process  by 
focusing  on  what  exchanges  take  place  and  who  is  affected.  It  can  also  be 
used  to  help  define  new  ways  of  reviewing  multiple  design  options  and  in¬ 
tegrating  them  into  the  overall  process. 

The  detailed  Exchange  Requirements  derived  from  the  following  task  de¬ 
scriptions  are  described  in  the  next  chapter. 

2.2.1  Criteria  Phase  electrical  system  design 

The  Criteria  Phase  consists  of  the  following  tasks,  shown  diagrammatically 
in  Figure  1. 
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Figure  1.  Process  diagram  for  Criteria  Phase  electrical  system  design. 
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Task  Form 

Task  ID 

10-010  Task  Name  Develop  Facility  Occupancy  Model 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Building  Owner,  Building  Codes 

10 

Actor 

Architect 

10 

Information 

Required 

Site  Location  Information 

Owner’s  Project  Requirements 

■  Facility  Type,  Space  Types,  Area  Standards,  Occupant  Load,  Hours  of 
Occupancy  and  design  priorities,  Climate  Control  requirements 

Building  Code  Requirements 

Current 

Methods 

Architect  receives  document(s)  from  the  Owner.  Architect  uses  these  docu¬ 
ments,  in  conjunction  with  Building  Code  guidelines  and  standards  to  develop 
the  Facility  Occupancy  Model. 

Task  Form 

Task  ID 

10-020  Task  Name  Document  Electrical  Project  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Building  Owner,  Architect 

10 

Actor 

Electrical  Engineer 

10 

Information 

Required 

Project  Location  (determines  climate,  applicable  buildinq  codes,  utility  rate  struc- 
tures) 

Occupation  Factors:  number  of  occupants,  hours  of  occupancy,  occupancy  type 

Cost  Factors:  level  of  finishes 

Architectural  Factors:  size  of  building  (area),  number  of  floors,  floor  height 

Buildinq  Environments:  heatinq,  coolinq,  central/unitarv 

Illumination  Criteria:  liqhtinq  level,  liqht  sources,  davliqhtinq,  footcandles  req’d, 
indoor/outdoor/site  lighting 

Mechanical  Systems:  pumps,  chillers,  fans  (Power/Area  for  each  space) 

Buildinq  Equipment:  elevators,  production  equip. 

Auxiliary  Systems:  automation,  fire  alarm,  security,  data,  liqhtinq  controls,  life 
safety,  severe  weather,  telecom  (data/phone) 

Sustainability  Criteria:  LEED 

Future  Needs:  spare  electrical  capacity 

Current 

Methods 

Determine  system  types  for  consideration 

Determine  scope  of  major  HVAC  equipment 

Determine  power  density  at  buildinq  scope 
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Task  Form 

Task  ID 

10-030  Task  Name  Propose  Electrical  Equipment  Room  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

10 

Information 

Required 

Equipment  list 

Current 

Methods 

Verify  owner’s  list  of  equipment  that  may  impact  electrical  load  and  location. 

Task  Form 

Task  ID 

10-040  Task  Name  Proqram  Spaces,  Area,  and  Budqet 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

10 

Information 

Electrical  Equipment  and  required  spaces  (Distribution  Board:  Footprint  Area, 
Access  Area 

Required 

Site  Lighting 

Current 

Methods 

Program  spaces  according  to  size  and  proximity  requirements. 

Verify  space  sizes  and  ideal  shapes  of  rooms  with  electrical  service  provider, 
including  equipment  sizes  and  clearances  around  and  between  equipment. 

Task  Form 

Task  ID 

10-050  Task  Name  Coordinate  Development  of  Concept  Design 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

10 

Information 

Required 

Space  types,  areas,  proximity  requirements  (e.g.,  external  utility  hookup) 

Current 

Methods 

Review  and  modify  spaces  and  areas  per  service  provider  and  consultant  input. 
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Task  Form 

Task  ID 

10-060  Task  Name  Select  Main  Electrical  System  Types 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

10 

Actor 

Electrical  Engineer 

10 

Information 

Required 

List  of  maior  equipment  consuminq  electricity: 

(Chillers,  Boilers,  Compressors,  Condensers,  Unitary  Equipment,  Air  Handlers, 
Transport  Elements  [e.g.  elevators]): 

Load,  Voltage,  System  Type, 

List  of  equipment  (if  any)  for  qeneratinq  electricity: 

(Generators,  Solar  Panels,  Wind  Turbines): 

Output  Voltage,  System  Type,  Generating  Capacity 

List  of  equipment  for  storinq  electricity: 

(UPS):  Connected  Load,  Uptime 

General-purpose  electrical  demand  in  buildinq: 

Space:  Power  Density  for  Lighting,  Appliances,  Equipment 

Buildinq  Layout:  Preliminary  building  spaces,  types  and  classifications 

Current 

Methods 

Determine  electrical  systems  -  three-phase  vs.  single-phase 

Determine  transformers  between  systems 

Task  Form 

Task  ID 

10-070  Task  Name  Develop  Electrical  Basis  of  Design 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

10 

Actor 

Electrical  Engineer 

10 

Information 

Required 

Utility  Service  Types  Available 

Electrical  System  Types 

Document  process  model,  constraints,  formulas,  and  tables  used  for  making 
decisions  on  electrical  design. 

Current 

Methods 

•  Lighting  calculations  showing  required  and  designed  foot-candles 

•  Estimated  panel  board  loading  (including  25%  extra  as  a  projection  of 
future  building  loads) 

•  A  projection/summation  of  the  panel  board  loads  to  justify  the  sizing  of 
the  building  transformers 

•  An  economic  analysis  to  justify  the  selection  of  either  120V/208V  or 
277Y/480V  on  the  secondary  side  of  the  building  transformers 

•  An  analysis,  for  the  277Y/480  V  choice,  as  to  whether  the  step  down 
transformer(s)  shall  be  large  central  units  or  smaller  units  placed 
throughout  the  building 

•  A  short-circuit  analysis  to  determine  the  AIC  rating  of  the  system  com¬ 
ponents. 

•  A  coordination  study  to  determine  the  circuit  breaker  settings  and  sys¬ 
tem  coordination. 

Examples: 

http://www.wright.edu/administration/construction/forms/public_forms/ 

designProcess/Electrical_Basis_of_Design_Standards_Guidelines.pdf 

https://www.neco.navy.mil/necoattach/ 

N4008011R061512  Final  Elect  Calcs  as  1  PDF. pdf 
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Task  Form 

Task  ID 

10-080  Task  Name  Determine  Source  of  Supply 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Electrical  Engineer 

10 

Information 

Required 

Utility  Rate  Structures,  Processes,  Approvals: 

•  Rate  structures  for  each  system  type,  time  intervals,  and  usage. 

•  Process  model  for  coordinating  electrical  utility  service. 

•  Approval  requirements. 

Example: 

www.lipower.org/pdfs/commercial/redbook/redbook.pdf 

Current 

Methods 

Perform  economic  analysis  to  justify  selection  of  electrical  supply  source(s). 

Task  Form 

Task  ID 

10-090  Task  Name  Propose  Electrical  Space  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

10 

Information 

Required 

List  of  major  equipment  for  consuming,  generating,  transforming,  and  storing 
electricity. 

Current 

Methods 

Estimate  and  verify  additional  voltage  requirements  (e.g.,  annual,  seasonal  or 
unusual  circumstances),  including  electrical  back-up  generators,  per  code  and 
ordinances.  Re-size  room  accordingly. 

Task  Form 

Task  ID 

1 0-  Task 

100  Name  Estimate  Energy  Performance 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

10 

Information 

Required 

Operating  Costs  (based  on  utility  rate  structures) 

Performance  History  (power  usage  time  series  at  hourly  intervals  for  year): 

Current 

Methods 

Calculate  operating  costs  at  system  level  based  on  current  rate  structures  from 
utility. 
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Task  Form 

Task  ID 

1 0-  Task 

110  Name  Document  Concept  Design  &  Estimated  Costs 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer,  Cost  Estimator 
(or  GC  in  negotiated  contractor 
situation) 

10 

Actor 

Architect 

10 

Information 

Required 

Space  Requirements: 

Space:  area,  relation  to  other  spaces,  exterior  requirements 

Mechanical  Requirements: 

Ventilation,  thermal  loads,  fuels 

Structural  Requirements: 

Weight 

Construction  Requirements  (primarily  for  existinq  construction): 

Installation  Method,  Clearances 

Construction  Costs  for  each  system: 

Systems:  Count 

Circuits:  Count 

Operatinq  Costs  (based  on  systems): 

Energy  performance  of  proposed  electrical  systems,  Performance  History  (power 
usage  time  series  at  hourly  intervals  for  year) 

Current 

Methods 

Calculate  construction  costs  at  system  level. 

Calculate  operating  costs  at  system  level. 

2.2.2  Schematic  Design  Phase  electrical  system  design 

The  Schematic  Design  Phase  consists  of  the  following  tasks,  shown  dia- 
grammatically  in  Figure  2. 
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Figure  2.  Process  diagram  for  Schematic  Design  Phase  electrical  system  design. 
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Task  Form 

Task  ID 

20-010  Task  Name  Locate  Electrical  Loads 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

10 

Actor 

Architect 

20 

Information 

Required 

Preliminary  Schedule  of  Electrical  Load  Types 

Light  fixtures,  outlets,  other  devices  consuming  electricity  (e.g.,  Unitary 

Equipment) 

Space  classification  and  requirements  indicating  power  density. 

Current 

Methods 

Architect  uses  the  recommendations  and  preliminary  schedule  from  the 

Electrical  Engineer  to  indicate  locations  of  major  electrical  loads  in  the  initial 
schematic  plans. 

Task  Form 

Task  ID 

20-020  Task  Name  Propose  Electrical  Equipment  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

20 

Actor 

Electrical  Engineer 

20 

Electrical  reauirements  for  all  buildina  systems 

Information 

Required 

Load  Types  and  Locations 

•  Space:  Type,  Lighting  Power  Density,  Appliance  Power  Density 

•  Zone:  Light  fixtures  within  zones 

•  Unitary  Equipment:  Unitary  A/C  locations  within  spaces 

•  Other  Major  Electrical  Loads:  Locations  within  spaces 

•  Provision  for  Voids:  Locations  for  raceways 

Current 

Methods 

Generate  One  Line  Diagram 
http://en.wikipedia.org/wiki/One-line_diagram 

Determine  process  for  acquiring  electrical  equipment  (e.g.,  design  assist)  and 
verify  that  the  process  is  acceptable  to  all  participating  parties 

Determine  connected  load  and  demand  load  for  each  space 

Determine  diversity  coefficients 

Determine  circuits 

Determine  loads  at  distribution  points 

Select  equipment  (or  candidates)  at  each  occurrence 

Task  Form 

Task  ID 

20-030  Task  Name  Propose  Electrical  Spatial  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Electrical  Engineer 

20 

Information 

Required 

Electrical  Equipment  List 

Lighting  Layout:  Surface  finish,  clearance 

Raceway:  Above  ceiling  clearance,  wall  construction  type  (masonry/studs,  etc.) 

Current 

Methods 

Electrical  Engineer  uses  the  Electrical  Equipment  List  and  preliminary 
architectural  plans  to  develop  proposed  Electrical  Space  Requirements. 
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Task  Form 

Task  ID 

20-040  Task  Name  Locate  and  Size  Electrical  Equipment  Room(s) 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Architect 

20 

Information 

Required 

Space:  Required  Area,  Required  Wall  Lengths 

Equipment  (e.g.,  Distribution  Board):  Clearance  Area 

Cable  Carrier:  Location,  Profile,  Access  Locations 

Current 

Methods 

Verify  location  of  service  access  to  site. 

Determine  site  lighting  loads  on  system. 

Reserve  space  for  electrical  use 

Reserve  site  areas  for  electrical  utilities 

Task  Form 

Task  ID 

20-050  Task  Name  Propose  Lighting  Layout 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer,  Architect 

20 

Actor 

Architect 

20 

Information 

Space:  Space  Type,  Lighting  Density,  Lighting  Type 

Required 

Light  Fixture:  Light  Source  Type,  Light  Emission 

Current 

Methods 

Arrange  layout  of  light  fixtures  in  spaces. 

Task  Form 

Task  ID 

20-060  Task  Name  Size  Electrical  System 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

20 

Actor 

Electrical  Engineer 

20 

Information 

Required 

Building  elements  (e.g.,  wall,  slab):  Materials,  Fire  rating  (hours) 

Electrical  Equipment  Locations 

Current 

Methods 

Review  and  verify  hourly  ratings  and  code  requirements  for  separations  between 
electrical  equipment  rooms  and  adjoining  spaces  (could  potentially  impact  room 
areas). 

Size  distribution  boards,  cables,  transformers 
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Task  Form 

Task  ID 

20-070  Task  Name  Create  Raceway  Layout 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Electrical  Engineer 

20 

Information 

Cable  Carriers:  Location,  Profile,  Axis  Path 

Required 

Cables:  Location  (containing  carrier),  Profile,  Axis  Path 

Current 

Methods 

Layout  plan  for  cables,  cores,  busbars 

Task  Form 

Task  ID 

20-080  Task  Name  Document  Electrical  Systems  Schematic  Design 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Electrical  Engineer 

20 

Information 

Required 

Systems 

•  Systems:  ID,  Voltage,  Type  (Electrical  subtype,  lighting  control,  life 
safety) 

•  Circuits:  ID,  Voltage  Type,  Wire  Size,  Continuous  Length,  Run  Length 

•  Elements:  Location,  Mounting,  Connections 

Panelboard  Schedules: 

•  Distribution  Boards:  Name,  Description,  Capacity,  Spare  Capacity 

•  Protective  Devices:  Load  Name,  Load  KVA  Lighting,  Load  KVA 
Receptacles,  Load  KVA  Other/Motor,  Over  Current  Amps,  Over  Current 
Protection,  Circuit#,  Phase  Balance  A/B/C. 

Equipment  Schedules: 

•  Equipment:  Name,  Mark,  Power,  Voltage,  Phase,  Speed,  Location, 
Controller  Accessories,  Controller  Type,  Controller  Size,  Panel 
Designation,  Branch  Circuit  Type,  Branch  Circuit  Size,  Conductor 

Phase,  Conductor  Ground,  Conduit  Size,  Notes 

•  Generation  Equipment:  Capacity,  Connected  Load,  Transfer  Switch 

Type,  Fuel  Type,  Single/Three-Phase 

Liqhtinq  Fixture  Schedules: 

•  Light  Fixture:  Type,  Description,  Applications,  Load  Type,  Supply  Volts, 
Watts  Per  Fixture,  Manufacturer,  Lighting  Power  Density  (LPD) 

•  Lamp:  Count,  Power,  Lamp  Code 

Feeder  Schedules: 

•  Cable  Segment:  Name,  Cable  Insulation,  Size  in  AWG  or  MCM,  Method 
of  Installation,  Overcurrent  Protection,  Connected  Load,  Demand  Load 

Current 

Methods 

Create  plans  from  building  model 

Create  schedules  from  items  and  attributes 
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Task  Form 

Task  ID 

20-090  Task  Name  Coordinate  With  Other  Building  Systems 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Architect 

20 

Information 

Required 

Electrical  Drawings  and  Specifications:  Electrical  plans  showing  equipment 
locations  as  well  as  cable  routing  and  connectivity 

Electrical  Schedules  for  equipment,  fixtures,  feeders,  panelboards. 

Current 

Methods 

Electrical  Engineer  sends  the  electrical  drawings  to  the  Architect. 

Task  Form 

Task  ID 

20-100  Task  Name  Estimate  Energy  Usage 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

20 

Actor 

Electrical  Engineer 

20 

Information 

Required 

Load  profile  at  each  device  consuming  electricity 

Generation  profile  at  each  device  generating  electricity 
(Load  at  hourly  intervals  throughout  year) 

Service  Location 

Total  Area 

Conditioned  Space  Area 

Type  of  Heat 

Similar  Business:  Name,  Address,  Utility  Account# 

Type  of  Service:  Underground,  Overhead,  Service  Change,  Relocation,  New, 
Temporary 

Service  Characteristics:  Size  of  Load  Wires,  Sets  of  Load  Wires  Per  Phase, 

Load  Wire  Type  (AL/CU),  Terminations: 
Meterbase/C.T.Cabinet/ConnectionBox/Switchgear/Other 

Service  Size  (amp):  100/150/200/300/400/600/other 

Voltage:  1P3W-1 20/240,  3P4W-1 20/240  (<=200  amps),  3P4W-Wye-1 20/208, 
3P4W-Wye-277/480,  Other 

Electric  Load  Excluding  Motor  Load  (kW):  Interior  Lighting,  Exterior  Lighting, 
Electric  Cooking,  Water  Heating,  Dryer,  Heat  Pump,  Heat  Pump  Strip  Heat, 
Computers,  Receptacles,  Refrigeration,  Electric  Heat,  AC  (tons):  Data 

Processing  Load  Only,  Not  Including  Data  Processing 

Electric  Motor  Load  (Except  Heating  and  AC):  Phase,  Number  of  Motors,  HP, 
Voltage,  Hours  of  Operation  per  week 

Estimated  Business  Operating  Time:  Hours  Per  Week,  Month  Per  Year 

Meter  Location  Desired 

Service  Equipment  Location  Desired 

Current 

Methods 

Calculate  connected  loads  and  demand  loads  at  each  circuit,  and  for  overall 
electrical  system. 

Submit  Load  Letter  (format  provided  by  utility),  with  values  specified  per  project. 
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2.2.3  Coordinated  Design  Phase  electrical  system  design 

The  Coordinated  Design  Phase  comprises  the  following  tasks,  shown  dia- 
grammatically  in  Figure  3. 


Figure  3.  Process  diagram  for  Coordinated  Design  Phase  electrical  system  design. 
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Task  Form 

Task  ID 

30-010  Task  Name  Update  Facility  Spatial  Configuration 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

20 

Actor 

Architect 

30 

Information 

Required 

Spatial  Elements  (Buildings,  Levels,  Spaces,  etc.) 

Building  Elements  (Walls,  Slabs,  Doors,  Windows,  etc.) 

Distribution  Elements  (Electrical,  HVAC,  Plumbing,  etc.) 

Spatial  Zones 

Systems  &  Circuits 

Connectivity  (Space  Boundaries,  Ports,  Connections,  Interferences) 

Actors  &  Assignments 

Current 

Methods 

Architect  revises  the  facility  spatial  configuration  plans  based  on  the  results  of  the 
coordination  that  took  place  at  the  end  of  Design  Schematic. 

Task  Form 

Task  ID 

30-020  Task  Name  Determine  Electrical  Supply  Requirements 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

Product  Type  Template: 

Electrical  system  performance  specifications 
■  Cable  segment:  size,  location,  amps,  resistance 

Schedules  of  Electrical  Fixtures  and  Devices 

Updated  Electrical  Equipment  Sizes 

Updated  Location  of  Electrical  Fixtures  &  Equipment 

■  Electrical  Plan 

System  Tvpe 

■  Voltage,  Phases 

Electrical  Engineer  uses  the  Product  Type  Template  and  updated  plans  and  other- 
discipline  information  to  determine  total  electrical  supply  requirements. 

Current 

Methods 

Select  from  compatible  product  types  for  each  product  occurrence. 

[or  if  required,  select  3  compatible  product  types  that  are  suitable] 

Obtain  owner’s  approval. 
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Task  Form 

Task  ID 

30-030  Task  Name  Calculate  System  Loads 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

Element:  Load,  Time-phased  load 

Circuit:  Connected  Load,  Demand  Load,  Time-phased  load 

System:  Connected  Load,  Demand  Load,  Time-phased  load 

Diversity  Coefficient 

Current 

Methods 

Add  connected  loads  and  demand  loads  at  each  circuit,  multiply  by  coefficients 

Task  Form 

Task  ID 

30-040  Task  Name  Create  Cabling  Schematic 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect,  Electrical  Engineer 

30 

Actor 

Electrical  Engineer 

30 

Facility  Spatial  Confiquration 

Information 

Required 

Detail  Layout 

•  Switch:  Location,  Lighting  Load,  Controls 

•  Outlet:  Location,  Appliance  Load 

•  Cable  Segment:  Location,  Connections,  Load,  Length,  Wiring  method 
(EMT/ENT/MC/Rigid/etc.) 

•  Switchgear/Panels 

•  Junction  Box:  Location  (note:  may  not  be  at  this  level  of  detail) 

•  Life  Safety  devices  /  control  panels:  Location 

•  Lighting:  Location 

•  Telecom:  Location 

•  Generating  Equipment:  controls,  transfer  switches,  interconnects: 

Location 

For  all  products 

•  Product  Type:  Manufacturer,  Model,  (Specifications) 

•  Product  Resource:  Supplier,  Location,  Cost 

Current 

Methods 

Layout  Raceways,  Circuits,  Distribution  Equipment 

Task  Form 

Task  ID 

30-050  Task  Name  Redistribute  End  User  Circuits 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

Electrical  Topoloqy 

Electrical  Circuits:  Capacity,  Connected  Load,  Demand  Load,  Desired  Load  Factor 
Range,  Future  Expansion 

Current 

Methods 

For  circuits  with  loads  above  desired  factor,  split  into  separate  circuits. 

For  circuits  with  loads  below  minimum  factor,  combine  circuits 
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Task  Form 

Task  ID 

30-060  Task  Name  Update  Cabling  and  Equipment  Size 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

Updated  electrical  layout 

Electrical  Circuits:  Capacity,  Connected  Load,  Demand  Load,  Desired  Load  Factor 
Range,  Future  Expansion 

Current 

Methods 

Electrical  Engineer  updates  the  schedules  of  raceways,  cables,  and  equipment 
sizes. 

Task  Form 

Task  ID 

30-070  Task  Name  Select  Architectural  Light  Fixtures 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Architect,  Electrical  Engineer 

30 

Actor 

Architect 

30 

Information 

Required 

Light  Fixture:  specific  type,  or  assignment  of  3  approved  types 

Current 

Methods 

Select  suitable  type(s)  from  vendor  catalogs 

Task  Form 

Task  ID 

30-080  Task  Name  Develop  Product  Type  Specifications/Candidates 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer,  Architect 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

Updated  electrical  cables  and  equipment 

Light  fixture  schedules 

Calculated  load  at  main  electrical  equipment 

Current 

Methods 

Resize  to  meet  capacity,  selecting  alternate  product  types  that  fit  requirements. 

Task  Form 

Task  ID 

30-090  Task  Name  Update  Facility  Spatial  Configuration 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer,  Architect 

30 

Actor 

Architect 

30 

Information 

Required 

Updated  electrical  layout 

■  Electrical  Plan(s)  -  Fixtures,  Equipment,  Cable  routing,  distribution 
sources 

Updated  electrical  spatial  requirements 

Current 

Methods 

Architect  revises  the  facility  spatial  configuration  plans  based  on  the  updated 
electrical  layout  and  spatial  requirements  provided  by  the  Electrical  Engineer. 
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Task  Form 

Task  ID 

30-100  Task  Name  Document  Electrical  Design  Coordinated 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

30 

Actor 

Electrical  Engineer 

30 

Information 

Required 

All  information  from  20-080  plus: 

•  Types  (manufacturer/model)  -  either  exact,  generic  with  or  without 
assigned  types  that  meet  requirements 

•  Placement  (e.g.,  junction  boxes) 

•  Connectivity 

•  Wiring  Paths 

•  Controls/transfers 

•  Connections/Disconnects 

Current 

Methods 

Create  plans  with  detail  on  elements. 

Create  schedules  based  on  elements  and  acceptable  product  types. 

Task  Form 

Task  ID 

30-110  Task  Name  Coordinate  With  Other  Building  Systems 

Participants 

Roles  Involved 

Phase 

Information 

Provider 

Electrical  Engineer 

30 

Actor 

Architect 

30 

Information 

Required 

Updated  Electrical  drawings  showing  physical  size  and  location  of  all  elements  in 
the  electrical  system 

Final  Electrical  Specifications 

Updated  Drawings  from  all  other  Disciplines 

Current 

Methods 

Electrical  Engineer  sends  the  electrical  drawings  to  the  architect.  Architect 
incorporated  the  information  into  the  design. 
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3  Fundamental  Concepts 

3.1  Overview 

This  chapter  documents  common  concepts  of  information  modeling  ap¬ 
plied  to  various  object  types  found  in  data  exchanges.  Each  individual  con¬ 
cept  template  may  also  be  referred  to  as  a  functional  part,  and  describes  a 
graph  of  object  classes  and  attributes.  Such  templates  are  further  refined 
at  each  applicable  object  class  to  indicate  specific  values  or  types  that  may 
be  used.  For  a  complete  presentation  of  the  MVD,  including  IFC  instance 
diagrams  and  tables  indicating  how  the  concepts  are  used  by  entities  for 
exchanges,  see  http://docs.buildingsmartalliance.org/MVD  SPARKIE. 

3.2  Concept  templates 

Various  concept  templates  have  been  introduced  in  this  specification,  and 
existing  concept  templates  have  been  adapted  from  the  IFC4  specification 
of  BuildingSmart  International  fwww.buiidingsmart-tech.org). 

NOTE:  This  specification  is  also  available  in  HTML  and  MVDXMLform, 
where  the  online  specification  contains  additional  content  including  in¬ 
stantiation  diagrams  and  exchange  requirements  tables. 

This  specification  consists  of  a  schema  defining  data  types,  along  with 
common  concepts  indicating  use  of  data  types  for  particular  scenarios. 
This  chapter  defines  such  common  concepts,  which  are  applied  at  entities 
having  specific  use.  Such  concepts  also  form  the  basis  of  Model  View  Defi¬ 
nitions,  which  are  supplementary  specifications  that  adapt  the  scope  and 
rules  of  this  schema  for  targeted  domains  within  the  building  industry. 

Each  concept  template  defines  a  graph  of  entities  and  attributes,  with  con¬ 
straints  and  parameters  set  for  particular  attributes  and  instance  types. 
Various  entities  within  this  schema  reference  such  concept  templates  and 
adapt  them  for  particular  use  according  to  parameters.  For  example,  the 
'Ports'  concept  template  defines  distribution  system  connectivity  for  me¬ 
chanical,  electrical,  and  plumbing  systems  and  a  pipe  segment  defines  an 
application  of  the  'Ports'  concept,  having  one  port  as  an  inlet  and  another 
as  an  outlet. 
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3.2.1  Roots 

All  entities  having  semantic  significance  derive  from  IfcRoot,  where  in¬ 
stances  are  identifiable  within  a  data  set  using  a  compressed  globally 
unique  identifier  (IFC-GUID).  This  identifier  must  never  change  during 
the  lifetime  of  an  object,  which  allows  data  to  be  merged,  versioned,  or  ref¬ 
erenced  from  other  locations. 

Resource-level  instances  (not  deriving  from  IfcRoot)  do  not  have  any  iden¬ 
tity,  such  that  two  instances  having  identical  state  are  considered  equal. 
For  example,  if  an  object  has  coordinates  described  by  an 
IfcCartesianPoint  instance,  another  object  with  the  same  coordinates  may 
have  a  separate  instance  of  IfcCartesianPoint  or  share  the  same  instance; 
such  difference  is  a  matter  of  data  storage  optimization  and  does  not  imply 
any  semantic  relationship.  This  also  implies  that  non-rooted  instances 
may  only  exist  if  referenced  by  at  least  one  rooted  instance  through  either 
a  direct  attribute  or  inverse  attribute,  or  following  a  chain  of  attribute  ref¬ 
erences  on  instances. 

The  distinction  between  rooted  and  non-rooted  (resource-level)  entities 
achieves  several  goals: 

•  File  size  may  be  reduced  by  interning  (sharing)  non-rooted  data  in¬ 
stances; 

•  Database  retrieval  may  be  more  efficient  by  storing  non-rooted  data 
local  to  rooted  data  instances; 

•  Storage  size  may  be  reduced  by  avoiding  IFC-GUID  storage  for  items 
not  requiring  direct  retrieval; 

•  Comparisons  of  differences  may  be  done  at  a  higher  level  where  the 
context  of  such  change  is  apparent; 

•  Implementations  may  treat  non-rooted  data  instances  as  immutable 
for  efficiency  or  simplified  usage. 

3.2. 1.1  Identity 

An  object  needs  to  be  identifiable  for  accurate  processing  by  both  human 
and  automated  processes.  Identification  may  be  through  several  attributes 
such  as  Identification,  Name,  Description  or  GUID.  The  GUID  is  com¬ 
pressed  for  the  purpose  of  being  exchanged  within  an  IFC  data  set  -  the 
compressed  GUID  is  referred  to  as  "IFC-GUID".  While  the  IFC-GUID  is 
normally  generated  automatically  and  has  to  be  persistent,  the  Identifica- 
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tion  may  relate  to  other  informal  registers  but  should  be  unique  within  the 
set  of  objects  of  the  same  type.  The  Name  and  Description  should  allow 
any  object  to  be  identified  in  the  context  of  the  project  or  facility  being 
modeled. 

Various  objects  may  have  additional  identifications  that  may  be  human- 
readable  and/or  may  be  structured  through  classification  association. 

Various  file  formats  may  use  additional  identifications  of  instances  for  se¬ 
rialization  purposes;  however  there  is  no  requirement  or  guarantee  for 
such  identifications  to  remain  the  same  between  revisions  or  across  appli¬ 
cations.  For  example,  the  IFC-SPF  file  format  lists  each  instance  with  a  64- 
bit  integer  that  is  unique  within  the  particular  file. 

3.2.2  Project 

All  files  contain  a  single  IfcProject  instance  indicating  overall  context  and 
a  directory  of  objects  contained  within. 

3.2.2. 1  Project  declaration 

The  project  provides  a  directory  of  objects  contained  within  using  declara¬ 
tion  relationships 

3. 2. 2. 1.1  Object  type  definitions 

Declaration  of  object  types,  such  as  element  types  utilized  by  the  element 
occurrences  within  this  project,  within  the  context  of  the  project 

3.2. 2. 1.2  3.  Property  set  templates 

Declaration  of  property  set  templates,  including  the  property  templates 
that  are  used  as  property  definitions.  Such  templates  define  the  applicable 
properties,  their  names,  descriptions,  measure  types  and  property  type 
(single,  enumerated,  bounded  list  or  table  value). 

3. 2. 2. 2  Project  units 

The  project  context  includes  the  definition  of  the  default  units  within  the 
IFC  data  set.  Default  units  are  those  units  that  apply: 
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•  To  all  geometric  representation  items  within  the  geometric  representa¬ 
tion  contexts; 

•  To  all  attributes  with  a  defined  datatype  indicating  a  measure  datatype; 

•  To  all  properties  and  quantities  with  a  defined  datatype  indicating  a 
measure  datatype  and  with  no  local  unit  definitions  provided. 

3. 2. 2. 3  Project  context 

A  project  representation  context  indicates  the  coordinate  system  orienta¬ 
tion,  direction  of  true  north,  precision,  and  other  values  that  apply  to  all 
geometry  within  a  project  or  project  library.  3.2.3  Actor 

An  actor  is  a  person  or  organization  participating  in  a  project.  Actors  may 
fulfill  one  or  more  roles  such  as  engineers,  contractors,  manufacturers, 
building  occupants,  etc. 

3.2.2A  Contact 

Contact  information  indicates  roles  and  addresses  of  people  and  organiza¬ 
tions. 

3.2.3  Control 

A  control  is  a  directive  to  meet  specified  requirements  such  as  for  scope, 
time,  and/or  cost. 

3.2.3.1  Cost 

Cost  information  is  used  to  indicate  rate  structures  within  a  cost  schedule 
which  are  applicable  to  assigned  objects. 

3.2. 3.2  Calendar 

Calendar  information  is  used  to  filter  other  objects  to  indicate  time  periods 
during  which  the  control  applies. 

3.2.4  Product 

A  product  is  an  occurrence  of  a  physical  or  virtual  object  with  finite  spatial 
extent. 
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3.2.4. 1  Product  placement 

Product  occurrences  can  be  placed  in  3D  space  relative  to  where  they  are 
contained.  Placement  is  defined  by  a  relative  position  (X,  Y,  Z  coordi¬ 
nates),  a  horizontal  reference  direction,  and  a  vertical  axis  direction.  At  the 
outermost  level,  relative  directions  are  defined  according  to  representation 
context;  for  example,  +X  may  point  east,  +Y  may  point  north,  and  +Z  may 
point  up. 

Placement  follows  aggregation  and  containment  relationships  as  follows: 

•  At  the  outermost  level,  a  site  is  globally  positioned  according  to  lati¬ 
tude,  longitude,  and  elevation; 

•  For  spatial  structures,  positioning  is  relative  to  aggregation.  For  exam¬ 
ple,  a  site  may  aggregate  multiple  buildings,  each  building  may  aggre¬ 
gate  multiple  building  stories,  and  each  building  story  may  aggregate 
multiple  spaces; 

•  For  building  elements,  positioning  is  relative  to  the  containing  spatial 
structure.  For  example,  a  building  story  may  contain  slabs,  walls,  col¬ 
umns,  and  beams; 

•  For  aggregated  parts,  positioning  is  relative  to  aggregation.  For  exam¬ 
ple,  a  staircase  may  aggregate  one  or  more  stair  flights; 

•  For  feature  elements,  positioning  is  relative  to  the  affected  building  el¬ 
ement.  For  example,  an  opening  element  is  positioned  relative  to  the 
wall  it  voids,  which  in  turn  is  positioned  relative  to  a  building  story; 

•  For  fillings,  positioning  is  relative  to  the  filled  opening.  For  example,  a 
door  is  positioned  relative  to  an  opening  which  in  turn  is  positioned 
relative  to  a  wall; 

•  For  distribution  ports,  positioning  is  relative  to  the  containing  distribu¬ 
tion  element.  For  example,  an  air  terminal  may  have  a  port  connection 
for  a  duct  segment  or  fitting; 

•  For  distribution  elements,  positioning  is  relative  to  the  containing  spa¬ 
tial  structure,  however  may  be  constrained  by  port  connections.  For 
example,  an  electrical  junction  box  may  fill  an  opening  within  a  wall, 
and  the  junction  box  may  contain  ports  for  contained  outlets  or  switch¬ 
es;  the  placement  of  such  connected  elements  is  constrained  relative  to 
connected  port  of  the  junction  box.  As  another  example,  an  air  terminal 
may  fill  a  ceiling  covering  which  is  placed  relative  to  a  space;  the 
placement  of  a  connecting  duct  fitting  may  be  constrained  relative  to 
the  air  terminal. 
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If  a  containing  spatial  structure  contains  a  grid,  then  placement  may  also 
be  based  relative  to  grid  coordinates. 

3.2. 4.2  Product  representation 

The  shape  of  products  may  be  represented  in  multiple  ways  for  different 
purposes.  Each  representation  has  a  well-known  string  identifier  and  a 
particular  representation  context.  There  may  be  multiple  representation 
contexts  to  describe  a  shape  at  various  levels  of  detail.  Most  building  ele¬ 
ments  have  a  'Body'  representation  which  defines  or  approximates  the 
physical  shape  and  volume.  In  addition  to  physical  building  elements, 
non-physical  elements  may  have  representations  such  as  spaces  and  open¬ 
ings. 

3.2.4.2.1  Axis  geometry 

Elements  following  a  path  provide  an  'Axis'  representation  indicating  a 
line  segment  or  any  arbitrary  open  bounded  curve.  Examples  of  such  ele¬ 
ments  include  walls,  beams,  columns,  pipes,  ducts,  and  cables.  For  ele¬ 
ments  that  have  a  material  profile  set  association  indicating  cross-section, 
a  'Body'  representation  may  be  generated  based  on  the  axis  curve  and  ma¬ 
terial  profiles.  Curve  styles  may  indicate  particular  colors,  line  thicknesses, 
and  dash  patterns  for  2D  rendering. 

3. 2. 4-2. 2  Footprint  geometry 

Elements  filling  a  boundary  provide  a  'Footprint'  representation  indicating 
a  rectangle  or  any  arbitrary  set  of  outer  and  inner  boundary  curves.  Exam¬ 
ples  of  such  elements  include  slabs  and  spaces.  For  elements  that  have  a 
material  layer  set  association  indicating  material  thicknesses,  a  'Body'  rep¬ 
resentation  may  be  generated  based  on  the  footprint  and  material  layers. 
Fill  area  styles  may  indicate  particular  colors,  tiles,  or  hatching  for  2D  ren¬ 
dering. 

The  representation  identifier  of  the  footprint  geometric  representation  is: 
IfcShapeRepresentation.Representationldentifier  =  'Footprint' 
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3.2.4.2.3  Surface  geometry 

Elements  may  have  a  'Surface'  representation  describing  the  outer  surface 
of  the  object.  Such  representation  may  be  used  for  hit-testing  objects  hav¬ 
ing  part  composition  such  as  framed  walls. 

3.2.4.2.4  Body  geometry 

Elements  may  have  a  'Body'  representation  describing  the  volumetric 
shape  of  the  object.  Such  representation  may  be  used  for  3D  rendering  or 
quantity  take-off.  Geometry  may  be  based  on  boundary  representations 
describing  outer  faces,  primitives  such  as  spheres  or  cones,  swept  solids 
such  as  profile  extrusions  or  revolutions,  Constructive  Solid  Geometry 
(CSG)  such  as  clippings  or  subtractions  of  other  shapes,  or  Non-Uniform 
Rational  B-Spline  (NURBS)  geometry.  Surface  styles  may  indicate  particu¬ 
lar  colors,  textures,  and  reflectance  for  3D  rendering. 

The  representation  identifier  of  the  body  representation  is: 

IfcShapeRepresentation.Representationldentifier  =  'Body' 

3.2.4.2.5  Lighting  geometry 

Elements  emitting  light  provide  a  'Lighting'  representation.  Examples  of 
such  elements  include  lamps  and  light  fixtures.  Such  representation  may 
be  used  for  3D  rendering  or  lighting  design. 

3.2.4.2.6  Clearance  geometry 

Elements  requiring  surrounding  space  for  clearance  provide  a  'Clearance' 
representation.  The  reason  for  clearance  space  may  be  due  to  ventilation, 
maintenance,  or  other  purpose.  Examples  of  such  elements  include  boilers 
and  chillers.  Such  representation  may  be  used  for  interference  checks, 
where  the  'Clearance'  representation  must  not  intersect  with  the  'Body' 
representation  of  other  objects,  though  may  intersect  with  the  'Clearance' 
representation  of  other  objects. 

3. 2. 4.3  Site  location 


The  site  location  may  be  used  to  determine  climate  conditions  and  appli¬ 
cable  building  codes. 
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3.2. 4. 4  Building  location 

The  building  location  may  indicate  the  address  as  found  on  a  map. 

3.2.4.5  Grid 

Grids  are  used  for  layout  according  to  rectangular,  triangular  or  circular 
patterns. 

3.2.5  Resource 

A  resource  represents  usage  of  something,  having  costs  and  environmental 
impacts. 

3.2.5. 1  Resource  cost 

Resources  can  have  associated  costs  indicating  financial  costs  and  envi¬ 
ronmental  impacts  incurred  according  to  a  specified  base  quantity. 

Each  cost  value  may  be  defined  using  a  constant  amount  or  calculated  ac¬ 
cording  to  specified  formula. 

3.2. 5. 2  Resource  quantity 

Resources  may  be  defined  according  to  a  base  quantity,  where  assigned 
tasks  consume  such  amount  of  resource  relative  to  an  output  quantity. 

For  work-based  resources  such  as  labor  and  equipment,  quantities  are 
based  on  time.  For  product-based  resources,  quantities  are  based  on 
count.  For  material-based  resources,  quantities  are  based  on  volume. 

3.2.6  Resource  type 

A  resource  type  represents  a  template  of  usage  of  something,  having  cost 
rates  and  environmental  impact  rates. 

3. 2. 6.1  Resource  cost  rate 

Resource  cost  rates  are  provided  for  anything  that  may  be  sold  in  quantity, 
such  as  product  models  that  may  be  ordered,  or  common  services  that  may 
be  priced  by  unit. 
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3.2.7  Association 

Association  refers  to  relating  objects  to  external  information  such  as  doc¬ 
uments,  databases,  and  classifications. 

3. 2.7.1  Classification 

Objects,  type  objects,  properties,  and  some  resource  schema  entities  can 
be  further  described  by  associating  references  to  external  sources  of  in¬ 
formation.  The  source  of  information  can  be: 

•  A  classification  system; 

•  A  dictionary  server; 

•  Any  external  catalogue  that  classifies  the  object  further; 

•  A  service  that  combine  the  above  features. 

An  individual  item  within  the  external  source  of  information  can  be  select¬ 
ed.  It  then  applies  the  inherent  meaning  of  the  item  to  the  object  or  prop¬ 
erty. 

3.2.7. 2  Material 

Any  product  or  product  type  can  have  associated  materials  indicating  the 
physical  composition  of  an  object.  Materials  can  have  representations  for 
surface  styles  indicating  colors,  textures,  and  light  reflectance  for  3D  ren¬ 
dering.  Materials  can  have  representations  for  fill  styles  indicating  colors, 
tiles,  and  hatch  patterns  for  2D  rendering.  Materials  can  have  properties 
such  as  density,  elasticity,  thermal  resistance,  and  others  as  defined  in  this 
specification.  Materials  can  also  be  classified  according  to  a  referenced  in¬ 
dustry  standard. 

An  object  can  be  comprised  of  a  single  material  or  a  set  of  materials  with  a 
particular  layout.  Several  examples  include: 

•  A  slab  may  have  an  associated  layer  of  concrete; 

•  A  beam  may  have  an  associated  I-Shape  profile  of  steel; 

•  A  door  may  have  associated  constituents  for  framing  and  glazing; 

•  A  port  may  have  an  associated  profile  and/or  material  flowing  through 
it  such  as  hot  water. 
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EXAMPLE:  Material  information  can  also  be  given  at  object  type,  defining 
the  common  material  data  for  all  occurrences  of  the  same  type.  It  is  then 
accessible  by  the  inverse  IsTypedBy  relationship  pointing  via 
HasAssociations  and  via  IfcRelAssociatesMaterial.RelatingMaterial  to 
the  material  information.  If  both  are  given,  then  the  material  directly  as¬ 
signed  to  object  occurrence  overrides  the  material  assigned  to  object  type. 

3.2.7.2.1  Material  profile  set 

Material  profile  sets  are  associated  with  elements  or  element  types  where 
materials  are  placed  in  cross-sections  of  specified  dimensions  following  a 
path  defined  at  occurrences  of  the  type.  Examples  of  such  products  are 
beams,  columns,  members,  reinforcing,  footings,  piles,  pipe  segments, 
duct  segments,  and  cable  segments. 

Material  profile  sets  are  associated  by  using  the  relationship 
IfcRelAssociatesMaterial  having  the  RelatingMaterial  pointing  to  an 
IfcMaterialProfileSet.  The  RelatedObjects  either  point  to  a  single  or  multi¬ 
ple  occurrences  of  IfcElement,  or  to  a  single  or  multiple  IfcElementType. 

EXAMPLE:  Material  profile  sets  can  be  provides  at  the  IfcColumnType, 
defining  the  common  material  information  for  all  occurrences  of  the  same 
column  type.  It  is  then  accessible  by  the  inverse  IsTypedBy  relationship  at 
IfcColumn  pointing  to  IfcColumnType  having  the  HasAssociations  inverse 
relationship  to  IfcRelAssociatesMaterial  with  RelatingMaterial  refering  to 
the  IfcMaterialProfileSet.  If  an  individual  material  association  is  provide  at 
the  IfcColumn  and  the  IfcColumnType,  then  the  material  directly  assigned 
to  IfcColumn  overrides  the  material  assigned  to  IfcColumnType. 

3.2. 7.2. 2  Material  profile  set  usage 

Material  profile  set  usage  defines  layout  at  occurrences  to  indicate  the  off¬ 
set  from  the  'Axis'  reference  curve  according  to  cardinal  point,  and  a  refer¬ 
ence  extent  such  as  for  a  default  column  height. 

3.2.8  Definition 

Objects  may  be  defined  by  having  a  number  of  properties,  where  such 
properties  may  be  organized  partially  (into  property  sets)  or  fully  (into 
templates). 
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3.2.8. 1  Object  typing 

Object  occurrences  can  be  defined  by  a  particular  object  type,  using  the 
Object  Typing  concept.  A  pair  of  entities  is  defined  for  most  semantic  ob¬ 
jects  -  an  object  occurrence  entity  and  a  corresponding  object  type  entity. 

EXAMPLE:  The  IfcTank  is  the  object  occurrence  entity  that  has  a  corre¬ 
sponding  IfcTankType  being  the  object  type  entity. 

On  instance  level,  an  object  occurrence  instance  may  have: 

•  Similar  state  as  its  object  type  instance  by  applying  all  characteristics 
defined  at  the  type; 

•  Overridden  state  for  particular  characteristics; 

•  No  defined  object  type  instance. 

•  Characteristics  defined  at  the  object  type  level  may  include: 

•  Common  naming  and  predefined  type; 

•  Common  properties  within  a  type  driven  property  set; 

•  Common  geometry  representations,  applied  as  mapped  representation 
to  each  occurrences; 

•  Common  material  assignments  (with  exception  of  material  set  usages); 

•  Common  definition  of  a  decomposition  structure. 

Many  object  occurrence  and  object  type  entities  have  an  attribute  named 
PredefinedType  consisting  of  a  specific  enumeration.  Such  predefined  type 
essentially  provides  another  level  of  inheritance  to  further  differentiate  ob¬ 
jects  without  the  need  for  additional  entities.  Predefined  types  are  not  just 
informational;  various  rules  apply  such  as  applicable  property  sets,  part 
composition,  and  distribution  ports. 

EXAMPLE:  For  scenarios  of  object  types  having  part  compositions,  such 
parts  maybe  reflected  at  object  occurrences  having  separate  state.  For  ex¬ 
ample,  a  wall  type  may  define  a  particular  arrangement  of  studs,  a  wall 
occurrence  may  reflect  the  same  arrangement  of  studs,  and  studs  within 
the  wall  occurrence  may  participate  in  specific  relationships  that  do  not 
exist  at  the  type  such  as  being  connected  to  an  electrical  junction  box. 

The  object  type  is  attached  using  the  IfcRelDefinesByType  objectified  rela¬ 
tionship  and  is  accessible  by  the  IsTypedBy  inverse  attribute.  Only  a  max¬ 
imum  one,  or  zero,  object  types  can  define  an  object  occurrence.  If  the 
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object  type  has  aggregated  elements,  such  objects  are  reflected  at  the  ob¬ 
ject  occurrence  using  the  IfcRelDefines ByObject  relationship. 

3. 2. 8. 2  Property  sets 

Any  specialization  of  object  can  be  related  to  multiple  property  set  occur¬ 
rences.  A  property  set  contains  multiple  property  occurrences.  The  data 
type  of  property  occurrence  are  single  value,  enumerated  value,  bounded 
value,  table  value,  reference  value,  list  value,  and  combination  of  property 
occurrences. 

3.2. 8. 3  Property  sets  for  types 

For  object  types,  property  sets  are  defined  directly. 

This  concept  is  used  by  entities  for  exchanges  as  shown. 

3.2.8. 4  Property  sets  for  performance 

For  performance  history,  properties  are  in  the  form  of  time  series,  for 
tracking  data  at  points  in  time. 

3.2.9  Composition 

Objects  may  be  composed  into  parts  to  indicate  levels  of  detail,  such  as  a 
building  having  multiple  stories,  a  framed  wall  having  studs,  or  a  task  hav¬ 
ing  subtasks.  Composition  may  form  a  hierarchy  of  multiple  levels,  where 
an  object  must  have  a  single  parent,  or  if  a  top-level  object  then  declared 
within  the  single  project  or  a  project  library. 

3.2.9. 1  Object  aggregation 

An  aggregation  indicates  an  unordered  part  composition  relationship  be¬ 
tween  the  whole  structure,  referred  to  as  the  "composite",  and  the  subor¬ 
dinate  components,  referred  to  as  the  "parts".  The  concept  of  aggregation 
is  used  in  various  ways.  Examples  are: 

•  Aggregation  is  used  on  building  elements  to  indicate  parts  such  as 
studs  within  a  wall; 

•  Aggregation  is  used  on  spatial  elements  to  indicate  a  spatial  structure 
such  as  a  story  within  a  building; 
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•  Aggregation  is  used  on  systems  to  indicate  subsystems  such  as  branch 
circuits. 

Aggregation  is  a  bi-directional  relationship,  the  relationship  from  the 
composite  to  its  parts  is  called  Decomposition,  and  the  relationship  from 
the  part  to  its  composite  is  called  Composition. 

3.2.9.1.1  Element  decomposition 

Element  decomposition  refers  to  an  aggregation  structure  where  the  ele¬ 
ment,  representing  the  composite,  is  decomposed  into  parts  represented 
by  other  elements. 

The  composite  then  provides,  if  such  concepts  are  in  scope  of  the  Model 
View  Definition,  exclusively  the  following: 

•  Placement  —  the  common  object  coordinate  system  to  which  the  parts 
are  placed  relative 

•  By  default  the  following  constraints  apply  to  an  element  being  decom¬ 
posed  by  Element  Decomposition: 

•  Body  Geometry  —  composite  is  constructed  from  the  sum  of  the  Body 
Geometry  of  the  parts; 

•  The  composite  shall  not  have  an  own  Body  Geometry,  body  geometry  is 
provided  at  the  parts; 

•  The  composite  shall  not  have  an  own  Material  assignment,  material  is 
assigned  to  the  parts. 

3.2.9 .1.2  Spatial  decomposition 

Spatial  decomposition  refers  to  an  aggregation  structure  where  a  spatial 
structure  of  the  project  is  decomposed  into  parts  represented  by  other  spa¬ 
tial  structure  elements.  The  spatial  structure  is  a  hierarchical  tree  of  spa¬ 
tial  structure  elements  (site,  building,  story,  space)  ultimately  assigned  to 
the  project.  Decomposition  refers  to  the  relationship  to  lower  level  ele¬ 
ments  (e.g.,  this  story  has  spaces). 

The  order  of  spatial  structure  elements  being  included  in  the  concept  are 
from  high  to  low  level:  IfcProject,  IfcSite,  IfcBuilding,  IfcBuildingStorey, 
IfcSpace.  Therefore  a  spatial  structure  element  can  only  has  parts  of  an  el¬ 
ement  at  the  same  or  lower  level. 
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3. 2. 9. 2  Object  nesting 

Nesting  indicates  an  ordered  arrangement  relationship.  Nesting  is  used: 

•  On  building  elements  to  indicate  features  placed  in  sequence  such  as 
ports. 

•  On  control  objects  to  indicate  specification  hierarchies. 

•  On  process  objects  to  indicate  subordinate  task  details. 

•  On  resource  objects  to  indicate  subordinate  resource  allocations. 

3. 2. 9. 3  Ports 

Ports  indicate  possible  connections  to  other  objects  according  to  specified 
system  types,  flow  direction,  and  connection  properties.  Ports  are  typically 
connected  between  devices  via  cables,  pipes,  or  ducts. 

Ports  may  have  placement  defined  indicating  the  position  and  outward 
orientation  of  the  port  relative  to  the  product  or  product  type. 

Ports  may  have  material  profile  sets  defined  indicating  the  flow  area  and 
connection  enclosure. 

3.2.10  Assignment 

Objects  may  provide  services  to  other  objects,  where  the  "assigned  from" 
object  acts  upon  or  observes  requirements  of  the  "assigned  to"  object. 
There  is  a  general  cycle  of  assignments  where  actors  (people)  issue  con¬ 
trols  (such  as  work  orders  or  schedules),  which  may  result  in  groups  (such 
as  building  systems)  comprised  of  products  (such  as  building  elements) 
operated  upon  by  processes  (such  as  construction  tasks)  performed  by  re¬ 
sources  (such  as  labor)  which  may  in  turn  be  fulfilled  by  actors  (people). 
Requirements  are  established  at  the  "to"  side  and  are  fulfilled  at  the  "from" 
side,  where  costs,  time,  scope,  or  other  metrics  may  be  calculated  in  the 
"from-to"  direction. 

3.2.10.1  Actor  assignment 

Actors  may  have  assignments  indicating  objects  for  which  they  have  re¬ 
sponsibility.  An  example  of  such  assignment  is  a  work  order  assigned  to  an 
organization. 
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3.2.10.2  Control  assignment 

Controls  may  have  assignments  indicating  objects  that  must  observe  the 
established  requirements.  An  example  of  such  assignment  is  a  labor  re¬ 
source  assigned  to  a  calendar. 

3.2.10.3  Group  assignment 

Group  Assignment  established  an  arbitrary  collection  of  objects  within  a 
group.  The  grouping  relationship  does  not  apply  any  other  meaning  then 
grouping  objects  under  some  aspect.  It  is  non-hierarchical,  that  is  objects 
can  be  grouped  into  different  logical  groups,  and  it  does  not  interfere  with 
other  relationship  concepts,  such  as  ObjectAggregation. 

The  Group  Assignment  concept  establishes  a  given  object  as  being  the 
group  collection  for  other  objects.  It  usually  implies  the  existence  of  a 
grouping  relationship  and  the  provision  of  some  identity  under  which  the 
group  is  characterized. 

The  group  collection  is  handled  by  an  instance  of  IfcRelAssignsToGroup, 
which  assigns  all  group  members  to  the  IfcGroup  being  the  collection. 

Objects  included  in  group  as  collected  items  are  linked  by  IsGroupedBy 
pointing  to  IfcRelAssignsToGroup 

NOTE:  The  IfcGroup  maybe  not  yet  have  a  grouping  relationship  estab¬ 
lished,  it  then  identifies  an  empty  group. 

EXAMPLE:  An  air  handler  belonging  to  an  air  conditioning  system  is  an 
example  of  such  group  assignment. 

3.2.10.4  Process  assignment 

Processes  may  have  assignments  indicating  resources  consumed  or  occu¬ 
pied  by  the  process.  An  example  of  such  assignment  is  a  carpenter  labor 
resource  building  a  wall. 

3.2.10.5  Resource  assignment 

Resources  may  have  assignments  indicating  sources  available  to  be  used. 
An  example  of  such  assignment  is  a  person  fulfilling  a  carpenter  labor  re¬ 


source. 
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3.2.10.6  Product  type  assignment 

Product  types  may  have  assignments  indicating  re-usable  process  types  for 
which  occurrences  may  operate  on  occurrences  of  the  product  type.  An  ex¬ 
ample  of  such  assignment  is  a  task  type  for  placing  concrete  in  slabs  on 
grade. 

3.2.10.7  Process  type  assignment 

Process  types  may  have  assignments  indicating  re-usable  resource  types 
for  which  occurrences  may  be  consumed  or  occupied  by  occurrences  of  the 
process  type.  An  example  of  such  assignment  is  a  concrete  mixer  resource 
type  for  delivering  concrete. 

3.2.11  Connectivity 

Objects  may  participate  in  various  connectivity  relationships  with  other 
objects. 

3.2.11.1  Spatial  structure 

Spatial  structures,  such  as  site,  building,  story,  or  spaces,  may  contain 
physical  elements,  including  building  elements,  distribution  elements,  and 
furnishing  elements.  The  containment  relationship  between  the  physical 
elements  and  the  spatial  structures  is  hierarchical,  i.e.  a  physical  element 
shall  only  be  contained  within  a  single  spatial  structure. 

EXAMPLE:  An  IfcBeam  is  placed  within  the  spatial  hierarchy  using  the 
objectified  relationship  IfcRelContainedlnSpatialStructure,  referring  to  it 
by  its  inverse  attribute  SELF\IfcElement.ContainedInStructure.  Subtypes 
of  IfcSpatialStructureElement  are  valid  spatial  containers,  with 
IfcBuildingStorey  being  the  default  container. 

The  spatial  containment  relationship,  together  with  the  Spatial  decompo¬ 
sition  relationship,  being  hierarchical  as  well,  establishes  the  hiearchical 
project  tree  structure  in  a  building  information  model. 

EXAMPLE:  The  IfcBuildingStorey  that  logically  contains  the  IfcBeam  de¬ 
composes  the  IfcBuilding  using  the  IfcRelAggregates  relationship.  There¬ 
fore  the  IfcBeam  is  also  indirectly  contained  in  the  building. 
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3.2.11.1.1  Spatial  containment 

The  Spatial  Containment  concept  defines  the  relationship  of  physical  ele¬ 
ments,  such  as  building  elements,  distribution  elements,  or  furnishing  el¬ 
ements  as  being  contained  within  a  spatial  structure  element. 

3.2.11.1.2  Space  coverings 

Spaces  may  have  related  coverings  for  floorings,  ceilings,  and  wall  cover¬ 
ings.  Such  relationship  provides  for  parametric  use  of  building  materials 
where  such  elements  may  automatically  adapt  to  changes  in  the  size,  lay¬ 
out,  and  openings  for  the  space. 

3.2.11.2  Element  connectivity 

Elements  may  be  connected  to  other  elements,  where  the  RelatingElement 
is  of  equal  or  higher  priority,  is  generally  constructed  first,  and/or  anchors 
the  RelatedElement. 

3.2.11.2.1  Port  connectivity 

Ports  on  objects  may  be  connected  using  elements  such  as  cables,  ducts,  or 
pipes. 

3.2.11.3  Interference 

Elements  may  interfere  with  other  elements,  such  as  cable  carriers  going 
through  walls.  The  interference  relation  enables  precedence  of  interfering 
elements  to  be  asserted. 
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4  Model  View  Definition 

4.1  Overview 

This  chapter  documents  use  cases  for  exchanging  information  related  to 
electrical  disciplines  for  building  design  and  construction.  Industry  Foun¬ 
dation  Classes  (IFC)  is  the  international  standard  for  exchanging  Building 
Information  Modeling  (BIM)  data,  which  defines  hundreds  of  classes  for 
common  use  in  software,  currently  supported  by  approximately  150  appli¬ 
cations.  A  Model  View  Definition  (MVD)  defines  a  subset  of  the  IFC  sche¬ 
ma  that  is  needed  to  satisfy  one  or  many  Exchange  Requirements  of  the 
AEC  industry.  Together  with  the  IFC  schema  subset,  a  set  of  implementa¬ 
tion  instructions  and  validation  rules,  called  MVD  Concepts,  are  pub¬ 
lished.  The  electronic  format  to  publish  the  concepts  and  associated  rules 
is  mvdXML.  While  IFC  defines  how  building  information  can  be  repre¬ 
sented  electronically  in  general,  an  MVD  defines  which  information  is  re¬ 
quired  for  particular  scenarios. 

4.2  Exchanges 

Information  required  at  various  stages  of  a  building  project  is  organized 
into  Exchanges.  Each  exchange  defines  what  information  is  required,  op¬ 
tional,  inapplicable,  or  restricted.  Application  software  may  support  filter¬ 
ing  data  to  be  imported  or  exported  for  a  particular  exchange,  and 
contracts  for  projects  may  refer  to  such  exchanges  to  identify  the  scope 
and  format  of  information  required  for  delivery. 

4.2.1  Facility  occupancy  model 

4.2.1. 1  Requirements 

The  facility  occupancy  model  describes  the  site  location,  owner's  project 
requirements,  and  building  requirements. 

The  site  location  indicates  the  geographic  location  for  determining  climate 
information,  and  the  legal  address  for  determining  the  jurisdiction  and 
applicable  building  codes. 
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The  owner's  project  requirements  consist  of  a  facility  type  and  a  set  of 
space  types,  each  indicating  occupancy  loads,  hours  of  occupancy,  design 
priorities,  and  climate  control  requirements. 

4.2. 1.2  Usage 

The  IfcProject  indicates  overall  context  including  default  units.  The 
IfcProject  is  aggregated  by  an  IfcSite  which  indicates  the  geographic  loca¬ 
tion  and  postal  address.  The  IfcSite  is  aggregated  by  an  IfcBuilding  which 
indicates  overall  building  requirements  in  the  form  of  property  sets.  The 
IfcProject  declares  IfcOccupant  instances  (via  IfcRelDeclares)  for  each 
class  of  building  occupant  which  may  correspond  to  a  number  of  people  as 
indicated  within  the  Pset_ActorCommon  property  set.  Each  IfcOccupant 
may  have  IfcWorkCalendar  assignments  using  IfcRelAssignsToActor.  The 
IfcProject  declares  IfcWorkCalendar  instances  (via  IfcRelDeclares)  for 
each  calendar  of  occupancy.  Each  IfcWorkCalendar  may  have  IfcBuilding 
assignments  using  IfcRelAssignsToControl. 

4.2.2  Electrical  project  requirements 

4.2.2. 1  Requirements 

Electrical  project  requirements  are  based  on  electrical  usage  criteria  as 
well  as  equipment  determined  from  usage  criteria  of  other  systems  such  as 
HVAC  and  other  mechanical  systems. 

•  Occupation:  Number  of  occupants,  hours  of  occupancy,  occupancy  type 

•  Cost:  Level  of  finishes 

•  Architectural:  Size  of  building,  number  of  floors,  floor  height 

•  Environment:  Heating,  cooling,  central/unitary 

•  Illumination:  Lighting  level,  light  sources,  daylighting,  site  lighting 

•  HVAC:  Pumps,  chillers,  fans  (power/area  for  each  space) 

•  Transport:  Elevators,  escalators 

•  Control:  Automation  systems 

4. 2. 2. 2  Usage 

The  IfcBuilding  contains  various  property  sets  for  indicating  overall  build¬ 
ing  requirements. 
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4.2.3  Equipment  room  requirements 

4.2.3. 1  Requirements 

This  exchange  captures  equipment  with  significant  electrical  loads. 

4.2. 3. 2  Usage 

Electrical  equipment  rooms  are  indicated  using  IfcSpace  with  classifica¬ 
tion  source  set  to  'Omniclass'  Table  13  ('Spaces  By  Function')  using  identi¬ 
fication  of  '13-81 31 11'  having  the  description  'Power  Distribution  Spaces', 
which  may  be  further  classified  according  to  more  specific  space  usage.  As 
the  building  spatial  hierarchy  is  not  yet  defined  at  this  stage,  the  IfcSpace 
is  declared  on  the  IfcProject  using  IfcRelDeclares,  and  has  no  placement  or 
representation  indicated.  The  IfcSpace  may  contain  equipment  (such  as 
IfcChiller,  IfcUnitaryEquipment,  or  IfcElectricDistributionBoard)  using 
IfcRelContainedlnSpatialStructure,  where  the  particular  locations  of  the 
equipment  are  not  yet  defined.  However,  representations  of  the  equipment 
are  required  to  determine  necessary  area  and  volume  using  the  'Body', 
'Footprint',  and  'Clearance'  representations. 

4.2.4  Space  program 

4.2.4. 1  Requirements 

Spaces  are  programmed  according  to  size  and  proximity  requirements. 
Equipment  sizes  and  clearances  must  be  provided. 

4. 2. 4. 2  Usage 

Spaces  are  indicated  using  IfcSpace  with  classification  source  set  to 
'Omniclass'  Table  13  ('Spaces  by  Function'),  which  may  be  further  classi¬ 
fied  according  to  specific  space  usage.  As  the  building  spatial  hierarchy  is 
not  yet  defined  at  this  stage,  the  IfcSpace  is  declared  on  the  IfcProject  us¬ 
ing  IfcRelDeclares,  and  has  no  placement  or  representation  indicated. 

Each  IfcSpace  may  contain  equipment  using 

IfcRelContainedlnSpatialStructure,  where  the  particular  locations  of  the 
equipment  are  not  yet  defined.  However,  representations  of  the  equipment 
are  required  to  determine  necessary  area  and  volume  using  the  'Body', 
'Footprint',  and  'Clearance'  representations. 


ERDC/CERL  CR-13-2 


46 


4.2.5  Coordinate  concept  design 

4.2.5. 1  Requirements 

Once  space  requirements  have  been  determined,  space  locations  and  di¬ 
mensions  are  allocated,  where  they  are  then  adjusted  according  to  specific 
disciplines  to  fulfill  more  detailed  requirements. 

4. 2. 5. 2  Usage 

Spaces  are  indicated  using  IfcSpace  with  classification  source  set  to 
'Omniclass'  Table  13  ('Spaces  by  Function'),  which  may  be  further  classi¬ 
fied  according  to  specific  space  usage.  The  building  spatial  hierarchy  is  de¬ 
fined  at  this  stage,  where  spaces  formerly  declared  on  the  IfcProject  using 
IfcRelDeclares  are  then  allocated  within  the  IfcBuilding  and 
IfcBuildingStorey  spatial  elements  using  IfcRelAggregates.  Placement  and 
representation  of  each  space  is  indicated,  including  'Body'  and  'Footprint'. 
Each  IfcSpace  may  contain  equipment  using 

IfcRelContainedlnSpatialStructure,  where  the  particular  locations  of  the 
equipment  are  not  yet  defined.  However,  representations  of  the  equipment 
are  required  to  determine  necessary  area  and  volume  using  the  'Body', 
'Footprint',  and  'Clearance'  representations. 

4.2.6  Electrical  system  types 

4.2.6. 1  Requirements 

Information  is  required  for  selecting  main  electrical  system  types. 

For  devices  consuming  electricity,  the  following  items  are  needed: 

•  Load 

•  Voltage 

•  System  Type 

For  devices  generating  electricity  (if  any),  the  following  items  are  needed: 

•  Capacity 

•  Output  Voltage 

•  System  Type 

For  devices  storing  electricity  (if  any),  the  following  items  are  needed: 
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•  Connected  Load 

•  Uptime 

For  spatial  electrical  demand,  the  following  items  are  needed: 

•  Lighting  power  density 

•  Appliance  power  density 

•  Equipment  power  density 

4. 2. 6. 2  Usage 

Electrical  systems  are  described  using  IfcDistributionSystem  having 
PredefinedType  set  to  ELECTRICAL.  Each  top-level  system  is  declared  on 
the  IfcProject  using  IfcRelDeclares.  Devices  within  each  system  (e.g. 
IfcChiller,  IfcTransportElement,  IfcElectricalGenerator)  are  assigned  us¬ 
ing  the  IfcRelAssignsToGroup  relationship,  where  property  sets  indicate 
power  requirements  on  devices. 

Systems  provided  by  utilities  are  assigned  to  the  utility  company  using 
IfcRelAssignsToActor  where  an  IfcActor  identifies  the  IfcOrganization  of 
the  utility  having  an  IfcActorRole  set  to  the  user-defined  value  of 
'UTILITY'.  Utility-level  systems  typically  contain  IfcTransformer  and 
IfcFlowMeter  elements. 

4.2.7  Electrical  basis  of  design 

4.2.7. 1  Requirements 

•  Document  process  model,  constraints,  formulas,  and  tables  used  for 
making  decisions  on  electrical  design. 

•  Lighting  calculations  showing  required  and  designed  foot-candles 

•  Estimated  panel  board  loading  (including  25%  extra  as  a  projection  of 
future  building  loads) 

•  A  projection/summation  of  the  panel  board  loads  to  justify  the  sizing  of 
the  building  transformers 

•  An  economic  analysis  to  justify  the  selection  of  either  120V/208V  or 
277Y/480V  on  the  secondary  side  of  the  building  transformers 

•  An  analysis,  for  the  277Y/480  V  choice,  as  to  whether  the  step  down 
transformer(s)  shall  be  large  central  units  or  smaller  units  placed 
throughout  the  building 
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•  A  short-circuit  analysis  to  determine  the  AIC  rating  of  the  system  com¬ 
ponents. 

•  A  coordination  study  to  determine  the  circuit  breaker  settings  and  sys¬ 
tem  coordination. 

4. 2. 7. 2  Usage 

To  indicate  multiple  scenarios  within  a  project,  each  scenario  is  indicated 
using  IfcWorkPlan  declared  on  the  IfcProject  using  the  IfcRelDeclares  re¬ 
lationship.  Once  a  plan  is  approved  for  usage,  it  may  be  nested  within  an 
approved  IfcProjectOrder.  Such  work  plan  may  have  a  nested 
IfcPerformanceHistory  record  indicating  projected  energy  usage,  which 
may  be  nested  into  sub-components  corresponding  to  subsystems.  The 
particular  systems  are  indicated  using  IfcDistributionSystem  and  are  as¬ 
signed  to  the  IfcPerformanceHistory  energy  projection  using  the 
IfcRelAssignsToControl  relationship. 

4.2.8  Electrical  source  of  supply 

4.2.8. 1  Requirements 

Rate  structures  must  be  defined  for  each  system  type,  indicating  time  in¬ 
tervals  and  usage. 

A  process  model  may  be  defined  coordinating  electrical  utility  service, 
along  with  approval  requirements. 

4.2.8.2  Usage 

Each  available  service  is  indicated  using  IfcTaskType  indicating  a  process 
model  with  PredefinedType  set  to  OPERATION.  Such  process  model  may 
have  nested  recurring  tasks  (IfcTask)  via  IfcRelNests  with  time  periods  in¬ 
dicating  when  the  service  applies  using  IfcTaskTimeRecurring.  Costs  of 
each  rate  structure  are  indicated  by  IfcSubContractResourceType  where 
BaseCosts  contains  one  or  more  IfcCostValue  instances.  Each 
IfcSubContractResourceType  is  assigned  to  the  IfcTaskType  or  nested 
IfcTask  using  the  IfcRelAssignsToProcess  relationship.  The  utility  (repre¬ 
sented  by  IfcActor)  is  assigned  to  the  subcontract  resource  type  using  the 
IfcRelAssignsToResource  relationship. 
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4.2.9  Electrical  space  requirements 

4.2.9. 1  Requirements 

Electrical  requirements  for  each  space  are  elaborated,  and  each  space  lists 
major  equipment  for  consuming,  generating,  transforming,  and  storing 
electricity. 

4.2.9. 2  Usage 

Spaces  are  indicated  using  IfcSpace  with  classification  source  set  to 
'Omniclass'  Table  13  ('Spaces  by  Function'),  which  may  be  further  classi¬ 
fied  according  to  specific  space  usage.  The  building  spatial  hierarchy  is  in¬ 
dicated  within  the  IfcBuilding  and  IfcBuildingStorey  spatial  elements 
using  IfcRelAggregates.  Placement  and  representation  of  each  space  is  in¬ 
dicated,  including  'Body'  and  'Footprint'.  Electrical  space  requirements  are 
defined  on  each  IfcSpace  using  property  sets,  particularly 
SPARKie_SpaceElectricalRequirements.  Each  IfcSpace  may  contain 
equipment  using  IfcRelContainedlnSpatialStructure,  where  the  particular 
locations  of  the  equipment  are  established  at  this  stage.  Representations  of 
the  equipment  are  also  required  to  determine  necessary  area  and  volume 
using  the  'Body',  'Footprint',  and  'Clearance'  representations. 

4.2.10  Energy  performance 

4.2.10.1  Requirements 

Energy  usage  is  estimated  based  on  major  equipment,  power  densities  in¬ 
dicated  at  spaces,  and  occupancy  schedules. 

4.2.10.2  Usage 

The  IfcProject  declares  one  or  more  IfcPerformanceHistory  instances, 
where  the  lifecycle  phase  should  be  set  to  DESIGNDEVELOPMENT  to  in¬ 
dicate  development-level  estimation  precision.  Top-level 
IfcPerformanceHistory  instances  (typically  one)  refer  to  electrical  usage  at 
a  main  utility  port,  typically  corresponding  to  that  on  the  SINK  side  of  an 
IfcFlowMeter  electrical  meter,  where  such  IfcDistributionPort  may  be  as¬ 
signed  to  the  IfcPerformanceHistory  via  the  IfcRelAssignsToControl  rela¬ 
tionship.  The  IfcPerformanceHistory  makes  use  of  the 
Pset_DistributionPortPHistoryCable  property  set  for  indicating  electrical 
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loads  at  periods  of  time,  where  each  IfcPropertyReferenceValue  points  to 
IfcIrregularTimeSeries. 

4.2.11  Document  concept  design 

4.2.11.1  Requirements 

A  completed  concept  design  contains  requirements  for  all  disciplines  as 
follows. 

•  Architectural:  For  each  space,  area  and  relation  to  other  spaces  is  indi¬ 
cated  along  with  any  exterior  space  requirements. 

•  Mechanical:  For  each  distribution  element,  ventilation,  thermal  loads, 
and  fuel  types  are  indicated. 

•  Structural:  For  each  element,  static  weight  is  indicated  as  well  as  dy¬ 
namic  loads  (such  as  from  elevator  accelerating). 

•  Construction:  For  large  equipment,  installation  methods,  sequencing, 
and  paths  are  indicated. 

•  Costs:  Construction  and  operation  costs  are  established  for  each  sys¬ 
tem. 

4.2.11.2  Usage 

The  IfcProject  contains  a  full  spatial  hierarchy,  with  instances  of 
IfcElement  subtypes  are  contained  in  spatial  elements  using 
IfcRelContainedlnSpatialStructure.  Property  sets  indicate  qualitative  re¬ 
quirements  using  IfcPropertySet.  Structural  weight  requirements  are  de¬ 
scribed  by  quantity  sets  holding  a  'NetWeight'  property.  Construction 
installation  paths  are  indicated  via  an  assigned  IfcAnnotation  of 
ObjectType  'Annotation  curve'  containing  an  'Axis'  representation,  and  as¬ 
signed  IfcTask  of  type  MOVE.  Costs  are  indicated  by  instances  of 
IfcConstructionResource  subtypes  assigned  to  IfcTask  instances  which 
qualify  the  type  of  task  for  which  costs  apply. 

4.2.12  Locate  electrical  loads 

4.2.12.1  Requirements 

Light  fixtures,  outlets,  and  other  devices  consuming  electricity  are  placed 
within  the  building.  The  quantity  and  layout  of  devices  is  determined  by 
space  classification  and  electrical  power  density  requirements. 
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4.2.12.2  Usage 

Electrical  devices  such  as  distribution  boards,  junction  boxes,  and  equip¬ 
ment  are  positioned  within  spaces  using 

IfcRelContainedlnSpatialStructure,  and  embedded  or  attached  to  wall 
coverings  or  ceiling  coverings  using  IfcRelConnectsElements.  Note  that 
IfcWall  and  IfcSlab  indicate  structural  elements;  for  example,  the  blocks  of 
a  CMU  wall  or  the  framing  of  a  stud  wall.  Drywall  and  brick  are  consider¬ 
ing  coverings  for  which  IfcCovering  is  connected  using 
IfcRelCoversBldgElements.  Devices  embedded  within  coverings  are  posi¬ 
tioned  such  that  the  origin  is  on  the  plane  of  the  positive  surface,  the  Axis 
is  perpendicular  to  the  surface,  and  the  RefDirection  points  in  the  +X  di¬ 
rection  of  the  surface  when  installed  with  normal  orientation.  Outlets  and 
switches  may  be  aggregated  within  junction  boxes  using  IfcRelAggregates 
and  hold  IfcDistributionPort  connections  via  IfcRelNests  linking  to  the  en¬ 
closing  junction  box,  which  in  turn  has  ports  connecting  to  upstream  and 
downstream  devices  within  the  same  IfcDistributionCircuit.  Loads  on  de¬ 
vices  are  indicated  using  property  sets,  specifically 
Pset_ElectricalDeviceCommon. 

4.2.13  Electrical  equipment  requirements 

4.2.13.1  Requirements 

For  each  space,  the  connected  load  and  demand  load  is  determined  along 
with  diversity  coefficients.  Lighting  zones  may  span  within  a  single  space 
or  across  multiple  spaces,  for  which  any  geometrically  contained  light  fix¬ 
tures  are  considered  part  of  the  zone.  Circuits  are  allocated  and  loads  are 
determined  at  distribution  points.  For  each  device  occurrence,  equipment 
is  specified  in  one  of  three  ways:  (a)  a  specific  product  model;  (b)  an  arbi¬ 
trary  specification  with  required  properties  indicated;  or  (c)  an  arbitrary 
specification  with  multiple  acceptable  product  models  indicated.  Locations 
where  raceways  may  later  be  positioned  are  allocated  using  IfcProxy  with 
custom  type  PROVISIONFORVOID. 

One-line  diagrams  may  be  derived  from  this  information. 

4.2.13.2  Usage 

Loads  are  indicated  at  IfcDistributionCircuit  and  IfcDistributionSystem 
using  property  sets.  Lighting  zones  are  indicated  using  IfcSpatialZone  hav¬ 
ing  PredefinedType  of  LIGHTING.  Device  occurrences  are  indicated  by 
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instances  of  IfcDistributionElement  subtypes  and  assigned  to 
IfcDistributionCircuit  circuits  using  IfcRelAssignsToGroup.  Type  defini¬ 
tions  are  indicated  by  instances  of  IfcDistributionElementType  subtypes 
defined  on  occurrences  using  IfcRelDefinesByType.  For  a  type  definition 
that  refers  to  a  specific  product  model,  the  property  set 
Pset_ManufacturerTypeInformation  is  included.  For  a  arbitrary  type  defi¬ 
nition  where  multiple  product  models  meet  the  specification,  such  product 
model  types  (IfcDistributionElementType  subtype)  may  be  assigned  to  the 
specification  type  (IfcDistributionElementType  subtype)  using 
IfcRelAssignsToProduct. 

4.2.14  Electrical  equipment  rooms 

4.2.14.1  Requirements 

For  electrical  equipment  rooms,  locations  and  connectivity  of  distribution 
boards  and  cable  carriers  are  determined. 

4.2.14.2  Usage 

Distribution  boards  are  indicated  using  IfcDistributionBoard  and  are  typi¬ 
cally  placed  on  walls  using  IfcRelConnectsElements.  Distribution  boards 
that  are  to  be  recessed  within  walls  should  fill  an  opening  (IfcOpening  with 
type  RECESS )  using  IfcRelFillsElements. 

4.2.15  Lighting  layout 

4.2.15.1  Requirements 

Lighting  may  be  arranged  to  indicate  specific  placement  of  fixtures.  Such 
fixtures  may  be  attached  or  hung  to  surfaces,  embedded  within  coverings, 
or  suspended  from  ceiling  grids.  The  quantity  of  fixtures  may  be  deter¬ 
mined  according  to  the  required  lighting  power  density  for  the  space  and 
the  power  of  each  fixture. 

4.2.15.2  Usage 

Light  fixtures  are  indicated  using  IfcLightFixture  and  are  contained  within 
spaces  using  IfcRelContainedlnSpatialStructure.  Light  fixtures  that  are 
attached  to  surfaces  should  use  IfcRelConnectsElements  where 
RelatedElements  contains  the  IfcLightFixture.  Light  fixtures  that  are  to  be 
recessed  within  walls  should  fill  an  opening  (IfcOpening  with  type 
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RECESS )  using  IfcRelFillsElements.  Light  fixtures  that  are  placed  within 
ceiling  grids  should  be  placed  within  an  IfcGrid  that  is  connected  to  the 
IfcCovering  corresponding  to  the  ceiling  grid. 

4.2.16  Size  electrical  system 

4.2.16.1  Requirements 

Sizing  electrical  systems  involves  review  and  verification  of  hourly  ratings 
and  code  requirements  for  separations  between  electrical  equipment 
rooms  and  adjoining  spaces  (could  potentially  impact  room  areas).  Infor¬ 
mation  in  this  exchange  is  used  to  size  distribution  boards,  cables,  and 
transformers. 

4.2.16.2  Usage 

Each  IfcCableSegment  must  be  sized  to  accommodate  the  rated  load, 
where  the  NEC  defines  required  wire  gauges  according  to  amps.  Each 
IfcDistributionBoard  must  be  sized  to  accommodate  the  number  of  cir¬ 
cuits  and  spare  capacity  for  future  expansion.  Each  IfcTransformer  must 
be  sized  to  accommodate  the  capacity  and  voltage  of  the  transformed  cir¬ 
cuit.  Property  sets  (particularly  Pset_ElectricalDevice)  indicate  electrical 
characteristics  of  devices. 

4.2.17  Raceway  layout 

4.2.17.1  Requirements 

Layout  of  raceways  indicates  paths  and  connectivity  of  each  raceway  along 
with  allocation  of  cables  within  raceways. 

4.2.17.2  Usage 

Raceways  are  indicated  using  IfcCableCarrierSegment  for  straight  seg¬ 
ments  and  IfcCableCarrierFitting  for  transitions.  A  single 
IfcCableCarrierSegment  may  be  defined  with  an  arbitrary  'Axis'  represen¬ 
tation  indicating  the  path,  where  specific  segments  and  fittings  are  elabo¬ 
rated  as  assigned  objects  at  finer  level  of  detail  using 
IfcRelAssignsToProduct.  Cable  carrier  segments  and  fittings  are  connected 
together  using  IfcDistributionPort  having  PredefinedType  of 
CABLECARRIER.  Cables  are  indicated  using  IfcCableSegment  and  are 
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contained  within  an  overall  IfcCableCarrierSegment  using 
IfcRelAggregates. 

4.2.18  Electrical  schematic  design 

4.2.18.1  Requirements 

Electrical  schematic  design  includes  information  needed  to  calculate  elec¬ 
trical  performance  in  its  entirety.  This  information  may  be  used  to  derive 
schedules  for  systems,  panelboards,  equipment,  light  fixtures,  and  feeders. 

4.2.18.2  Usage 

Electrical  systems  are  indicated  using  IfcDistributionSystem,  with  individ¬ 
ual  circuits  defined  by  IfcDistributionCircuit.  Panelboard  schedules  are 
derived  from  IfcDistributionBoard  and  aggregated  IfcProtectiveDevice  el¬ 
ements  for  each  circuit  breaker.  Equipment  schedules  are  derived  from 
instances  of  IfcFlowTerminal  subtypes  powered  by  electrical  power.  Light¬ 
ing  schedules  are  derived  from  IfcLightFixture  and  aggregated  IfcLamp 
elements  for  each  lamp.  Feeder  schedules  are  derived  from 
IfcCableSegment.  Property  sets  indicate  specific  values  at  each  object. 

4.2.19  Coordinate  with  other  building  systems 

4.2.19.1  Requirements 

For  coordination  with  other  building  systems,  plans  are  created  showing 
equipment  locations  as  well  as  cable  routing  and  connectivity.  Electrical 
Schedules  for  equipment,  fixtures,  feeders,  panelboards  are  derived. 

4.2.19.2  Usage 

Equipment  is  indicated  primarily  by  subtypes  of  IfcFlowTerminal, 
IfcFlowController,  and  IfcEnergyConversionDevice.  Equipment  specific  to 
a  space  is  placed  within  an  IfcSpace,  while  equipment  that  serves  multiple 
spaces  is  placed  within  an  IfcBuildingStorey.  Cables  connecting  equipment 
are  attached  to  ports  (IfcDistributionPort)  on  each  device  using 
IfcRelConnectsPorts. 


ERDC/CERL  CR-13-2 


55 


4.2.20  Estimate  energy  usage 

4.2.20.1  Requirements 

Energy  usage  is  estimated  based  on  load  profiles  of  major  equipment.  Es¬ 
timating  energy  usage  involves  calculating  connected  loads  and  demand 
loads  at  each  circuit,  and  for  the  overall  electrical  system.  The  end  result  of 
this  calculation  may  be  captured  in  a  Load  Letter  (format  provided  by  util¬ 
ity),  with  values  specified  per  project. 

•  Utilities  may  require  the  following  information  for  establishing  service: 

•  Load  profile  at  each  device  consuming  electricity 

•  Generation  profile  at  each  device  generating  electricity 

•  Service  Location 

•  Total  Area 

•  Conditioned  Space  Area 

•  Type  of  Heat 

•  Similar  Business:  Name,  Address,  Utility  Account  Number 

•  Type  of  Service:  Underground,  Overhead,  Service  Change,  Relocation, 
New,  Temporary 

•  Service  Characteristics:  Size  of  Load  Wires,  Sets  of  Load  Wires  Per 
Phase,  Load  Wire  Type  (AL/CU),  Terminations:  Meterbase/C.T.  Cabi¬ 
net/Connection  Box/Switchgear/Other 

•  Service  Size  (amp):  100/150/200/300/400/600/other 

•  Voltage:  1P3W-120/240,  3P4W-120/240  (<=200  amps),  3P4W-Wye- 
120/208,  3P4W-Wye-277/48o,  Other 

•  Electric  Load  Excluding  Motor  Load  (kW):  Interior  Lighting,  Exterior 
Lighting,  Electric  Cooking,  Water  Heating,  Dryer,  Heat  Pump,  Heat 
Pump  Strip  Heat,  Computers,  Receptacles,  Refrigeration,  Electric  Heat, 
AC  (tons):  Data  Processing  Load  Only,  Not  Including  Data  Processing 

•  Electric  Motor  Load  (Except  Heating  and  AC):  Phase,  Number  of  Mo¬ 
tors,  HP,  Voltage,  Hours  of  Operation  per  week 

•  Estimated  Business  Operating  Time:  Hours  Per  Week,  Month  Per  Year 

•  Meter  Location  Desired 

•  Service  Equipment  Location  Desired 

4.2.20.2  Usage 

The  IfcProject  declares  one  or  more  IfcPerformanceHistory  instances, 
where  the  lifecycle  phase  should  be  set  to  DESIGN SCHEMATIC  to  indi¬ 
cate  schematic-level  estimation  precision.  Top-level 
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IfcPerformanceHistory  instances  (typically  one)  refer  to  electrical  usage  at 
a  main  utility  port,  typically  corresponding  to  that  on  the  SINK  side  of  an 
IfcFlowMeter  electrical  meter,  where  such  IfcDistributionPort  may  be  as¬ 
signed  to  the  IfcPerformanceHistory  via  the  IfcRelAssignsToControl  rela¬ 
tionship.  The  IfcPerformanceHistory  makes  use  of  the 
Pset_DistributionPortPHistoryCable  property  set  for  indicating  electrical 
loads  at  periods  of  time,  where  each  IfcPropertyReferenceValue  points  to 
IfcIrregularTimeSeries. 

4.2.21  Facility  spatial  configuration 

4.2.21.1  Requirements 

This  exchange  enables  an  architect  to  revise  the  facility  spatial  configura¬ 
tion  plans  based  on  the  results  of  the  coordination  that  took  place  at  the 
end  of  Design  Schematic.  Required  information  includes: 

•  Spatial  Elements  (Buildings,  Levels,  Spaces,  etc.) 

•  Building  Elements  (Walls,  Slabs,  Doors,  Windows,  etc.) 

•  Distribution  Elements  (Electrical,  HVAC,  Plumbing,  etc.) 

•  Spatial  Zones 

•  Systems  &  Circuits 

•  Connectivity  (Space  Boundaries,  Ports,  Connections,  Interferences) 

•  Actors  &  Assignments 

4.2.21.2  Usage 

Project  participants  responsible  for  particular  systems  are  indicated  using 
IfcActor  with  assignments  through  IfcRelAssignsToActor. 

Interferences  with  other  building  elements  are  indicated  using 
IfcRellnterferesElements,  where  priorities  may  be  indicated  at  such  inter¬ 
section. 

4.2.22  Electrical  supply  requirements 

4.2.22.1  Requirements 

In  this  exchange,  an  electrical  engineer  uses  the  product  type  templates, 
updated  plans,  and  other  discipline  information  to  determine  total  electri¬ 
cal  supply  requirements.  For  each  electrical  device,  compatible  product 
types  are  selected  for  each  product  occurrence  (or  if  required,  three  com¬ 
patible  product  types  are  selected  that  are  suitable).  The  project  delivery 
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method  may  require  the  owner's  approval  for  final  product  selection.  The 
total  electrical  supply  requirements  are  calculated  on  each  circuit  accord¬ 
ing  to  connected  load,  demand  load,  and  diversity  factor. 

4.2.22.2  Usage 

For  each  electrical  device,  the  specified  type  or  range  of  types  is  defined 
using  IfcRelDefinesByType.  Overall  electrical  supply  requirements  are  es¬ 
tablished  at  property  set  on  IfcDistributionSystem  of  type  ELECTRICAL. 

4.2.23  System  loads 

4.2.23.1  Requirements 

Loads  are  calculated  by  rolling  up  elements,  circuits,  and  systems  as  fol¬ 
lows: 

•  Element:  Load,  Time-phased  load 

•  Circuit:  Connected  Load,  Demand  Load,  Time-phased  load 

•  System:  Connected  Load,  Demand  Load,  Time-phased  load,  Diversity 
Coefficient 

4.2.23.2  Usage 

Devices  are  indicated  using  instances  of  IfcDistributionElement  subtypes. 
Circuits  are  indicated  using  IfcDistributionCircuit  having  PredefinedType 
set  to  ELECTRICAL  and  have  devices  assigned  using 
IfcRelAssignsToGroup.  Systems  are  indicated  using  IfcDistributionSystem 
having  PredefinedType  set  to  ELECTRICAL  and  have  circuits  nested  using 
IfcRelNests. 

4.2.24  Cabling  schematic 

4.2.24.1  Requirements 

This  exchange  provides  detailed  information  for  connectivity  and  place¬ 
ment  of  devices  cables,  including  the  following: 

•  Switch:  Location,  Lighting  Load,  Controls 

•  Outlet:  Location,  Appliance  Load 

•  Cable  Segment:  Location,  Connections,  Load,  Length,  Wiring  method 
(EMT/ENT/MC/Rigid/etc.) 
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•  Switchgear/Panels 

•  Junction  Box:  Location  (note:  may  not  be  at  this  level  of  detail) 

•  Life  Safety  devices  /  control  panels:  Location 

•  Lighting:  Location 

•  Telecom:  Location 

•  Generating  Equipment:  controls,  transfer  switches,  interconnects:  Lo¬ 
cation 

All  products  may  have  defined  types  indicating  Manufacturer,  Model,  and 
Specifications.  Such  types  may  also  have  assigned  tasks  and  resources  for 
procurement,  where  resource  types  indicate  Supplier,  Location,  and  Cost. 

4.2.24.2  Usage 

All  electrical  devices  are  connected  together  via  ports  (IfcDistributionPort 
having  PredefinedType  of  CABLE  and  SystemType  of  ELECTRICAL), 
where  the  relationship  IfcRelConnectsPorts  has  RelatingPort  set  to  the 
power  source  (having  FlowDirection  of  SOURCE)  and  RelatedPort  set  to 
the  load  (having  FlowDirection  of  SINK).  Product  types  are  indicated  via 
subtypes  of  IfcDistributionElementType.  Costs  rates  for  product  types  are 
indicated  via  subtypes  of  IfcConstructionResourceType  assigned  to 
IfcTaskType  assigned  to  the  IfcDistributionElementType.  The  task  type 
qualifies  the  scenario  for  which  the  cost  applies. 

4.2.25  Redistribute  circuits 

4.2.25.1  Requirements 

This  exchange  is  used  to  rebalance  circuits  based  on  calculations  derived 
from  the  cabling  schematic.  Circuits  with  loads  above  a  maximum  factor 
may  be  split  into  separate  circuits.  Circuits  with  loads  below  a  minimum 
factor  may  be  combined. 

4.2.25.2  Usage 

Each  circuit  is  represented  using  IfcDistributionCircuit  with 
PredefinedType  set  to  ELECTRICAL.  Loads  may  be  calculated  according 
to  information  at  property  sets,  particularly 
Pset  ElectricalDeviceCommon. 
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4.2.26  Cabling  and  equipment  size 

4.2.26.1  Requirements 

Based  on  final  allocation  of  circuits,  cabling  and  equipment  sizes  may  be 
adjusted. 

4.2.26.2  Usage 

Cable  segments  are  indicated  using  IfcCableSegment,  where  cable  size  in¬ 
formation  is  indicated  via  IfcMaterialProfileSet. 

Raceways  are  indicated  using  IfcCableCarrierSegment,  where  cross  section 
is  indicated  via  IfcMaterialProfileSet. 

4.2.27  Architectural  light  fixtures 

4.2.27.1  Requirements 

For  this  exchange,  the  architect  selects  specific  light  fixture  models  (or  an 
approved  list  from  several  manufacturers). 

4.2.27.2  Usage 

Light  fixture  occurrences  are  indicated  by  IfcLightFixture,  where  the  se¬ 
lected  model  is  defined  by  IfcLightFixtureType  defined  using 
IfcRelDefinesByType.  To  indicate  multiple  accepted  models,  the  top-level 
model  (IfcLightFixtureType)  indicates  an  abstract  template  (not  having  a 
model  defined  via  Pset_ManufacturerTypeInformation)  and  has  candidate 
types  assigned  using  IfcRelAssignsToProduct.  Each  candidate  type  has 
model  information  defined  via  the  Pset_ManufacturerTypeInformation 
property  set. 

4.2.28  Product  type  specifications 

4.2.28.1  Requirements 

For  this  exchange,  the  engineer  selects  specific  electrical  equipment  mod¬ 
els  (or  an  approved  list  from  several  manufacturers). 

4.2.28.2  Usage 

Electrical  equipment  occurrences  are  indicated  by  various 
IfcDistributionElement  subtypes,  where  the  selected  model  is  defined  by 
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IfcDistributionElementType  defined  using  IfcRelDefinesByType.  To  indi¬ 
cate  multiple  accepted  models,  the  top-level  model 

(IfcDistributionElementType)  indicates  an  abstract  template  (not  having  a 
model  defined  via  Pset_ManufacturerTypeInformation)  and  has  candidate 
types  assigned  using  IfcRelAssignsToProduct.  Each  candidate  type  has 
model  information  defined  via  the  Pset_ManufacturerTypeInformation 
property  set. 

4.2.29  Document  coordinated  design 

4.2.29.1  Requirements 

The  coordinated  design  contains  full  detail  for  all  electrical  devices  and 
their  placement  and  interaction  with  other  services  within  the  building. 

4.2.29.2  Usage 

Electrical  elements  are  defined  using  subtypes  of  IfcDistributionElement, 
with  ObjectPlacement  and  Representation  set  for  all  instances.  Electrical 
distribution  ports  are  indicated  using  IfcDistributionPort,  where  all  ports 
having  FlowDirection  of  SINK  must  be  connected.  (Source  ports  may  not 
necessarily  be  connected  such  as  open  outlets  or  the  last  junction  box 
within  a  circuit.) 
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5  Conclusions 

In  developing  Model  View  Definitions,  the  challenge  is  to  extract  detailed 
information  from  industry  experts  yet  find  commonalities  that  could  be 
applied  generally  across  varying  project  delivery  methods,  participants, 
and  localities.  During  this  project  there  were  varying  levels  of  input.  Some 
experts  would  work  within  the  assumptions  of  the  preliminary  structure, 
others  would  alter  various  steps,  and  some  created  new  process  diagrams 
from  scratch.  Each  party  had  different  project  delivery  methods.  There¬ 
fore,  dependencies  were  factored  out  by  making  each  exchange  role-based, 
not  contract-based.  Achieving  this  level  of  granularity  required  many  more 
exchanges  than  traditionally  used  in  IFC  Model  View  Definitions.  For  ex¬ 
ample,  information  sent  to  a  utility  for  obtaining  rate  structures  and  con¬ 
nection  information  is  one  specific  exchange,  rather  than  being  lumped 
into  a  higher  level  category  such  as  “early  design.”  The  definition  of  role- 
based  exchanges  supports  a  variety  of  project  delivery  methods.  Where 
possible,  exchanges  were  aggregated  into  higher  levels  when  appropriate. 

Once  each  exchange  was  defined,  the  specific  information  needed  down  to 
the  attribute-level  of  detail  was  described,  leveraging  the  existing  scope  of 
the  IFC  data  model  where  possible.  While  most  product  geometry  infor¬ 
mation  was  already  well-defined  within  IFC  version  2x3  and  implemented 
by  many  vendors,  there  were  many  concepts  that  required  some  of  the 
lesser-supported  IFC  data  structures  and  some  that  required  the  expanded 
MEP  scope  in  IFC  version  4  to  achieve  adequate  levels  of  detail.  There 
were  also  many  cases  of  data  constructs  already  in  possible  in  the  IFC 
schema  but  never  detailed  in  the  documentation  -  some  examples  of  these 
include  indicating  multiple  approved  product  types,  ceiling  grids  for  light¬ 
ing  layout,  and  indicating  projected  power  usage  at  different  times  of  day 
throughout  a  year.  While  realizing  that  many  of  these  concepts  were  not 
supported  by  existing  COTS  software,  the  MVD  has  been  defined  to  allow 
partial  compliance  for  now,  but  with  allowances  to  later  relax  or  replace 
some  requirements  after  testing  models  produced  by  existing  software. 

In  detailing  functional  parts  used  within  the  model  view,  this  project  also 
contributed  new  concepts  back  to  IFC4  that  appeared  to  have  wider  uses 
in  other  disciplines  (as  IFC4  was  not  yet  finalized  at  the  time).  For  exam¬ 
ple,  a  functional  part  for  generically  mapping  data  to  spreadsheets  was 
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formalized  to  support  common  tables  such  as  lighting  schedules,  while  al¬ 
so  supporting  other  Model  View  Definitions  such  as  COBie;  this  functional 
part  also  involved  advancing  the  parametric  capability  of  IFC  with  the  abil¬ 
ity  to  generically  reference  object  attributes.  Similarly,  as  details  on  con¬ 
nections  between  equipment  were  elaborated,  such  uses  also  made  their 
way  into  expanded  port  specifications  within  IFC4. 

Once  the  Model  View  Definition  was  complete,  IFC  files  were  tested  with 
the  mvdXML  electronic  validation  format  and  noted  concepts  that  were 
supported  by  existing  software  and  those  requiring  new  functionality. 
There  were  some  very  basic  limitations  such  as  not  capturing  the  physical 
building  address,  which  is  required  for  determining  applicable  codes  and 
utilities,  and  more  complex  limitations  such  as  detailing  projected  utility 
usage.  In  trying  to  find  a  balance  that  would  encourage  faster  adoption  by 
vendors,  critical  concepts  were  strongly  enforced  while  others  were  relaxed 
by  making  certain  attributes  optional. 

Going  forward,  the  IFC4  release  and  supporting  technology  has  provided 
for  integrated  Model  View  Definitions  where  the  IFC  specification  and  all 
published  Model  View  Definitions  will  be  made  available  online  in  an  inte¬ 
grated  form.  This  will  enable  developers  of  IFC  to  instantly  cross-reference 
usage  of  entities  across  multiple  model  views  and  to  define  templates  only 
once  where  they  are  re-used  across  model  views.  The  supporting  mvdXML 
technology  provides  for  computer-interpretable  validation,  content  filter¬ 
ing,  sub-schema  generation,  and  data  adaptation.  This  enables  new  IFC 
software  vendors  to  support  information  models  with  a  substantially  lower 
barrier  of  entry,  and  enables  established  software  vendors  with  full  IFC 
support  to  handle  new  Model  View  Definitions  automatically  without  ad¬ 
ditional  work.  This  Model  View  Definition  is  one  of  the  first  to  leverage  the 
growing  ecosystem  of  mvdXML  and  has  influenced  the  future  direction  of 
IFC  with  the  various  supporting  concepts. 
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